From bugmaster at FreeBSD.org Mon Sep 1 11:07:00 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 1 11:08:33 2008 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200809011106.m81B6xJQ068516@freefall.freebsd.org> Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/111220 pf [pf] repeatable hangs while manipulating pf tables 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/82271 pf [pf] cbq scheduler cause bad latency o kern/92949 pf [pf] PF + ALTQ problems with latency o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented 6 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/93825 pf [pf] pf reply-to doesn't work s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/114095 pf [carp] carp+pf delay with high state limit o kern/114567 pf [pf] LOR pf_ioctl.c + if.c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o kern/121704 pf [pf] PF mangles loopback packets o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/125467 pf [pf] pf keep state bug while handling sessions between 10 problems total. From mksmith at adhost.com Tue Sep 2 17:22:04 2008 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue Sep 2 17:22:10 2008 Subject: Crazy Question - IPv6 to IPv4 and vice versa Message-ID: <17838240D9A5544AAA5FF95F8D520316049038B6@ad-exh01.adhost.lan> Hello All: I'm wondering if it would be possible to create a mapping between an "outside" IPv6 address and an "inside" IPv4 NAT (or round-robin group, to take it to the next logical step) or vice versa? This would be on a FreeBSD 7.0 installation. As a second note, if it's not supported now would it be possible to add this support? Regards, Mike -- Michael K. Smith - CISSP, GISP Chief Technical Officer - Adhost Internet LLC mksmith@adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 474 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20080902/3fe3d6f2/PGP.pgp From koitsu at FreeBSD.org Tue Sep 2 17:43:15 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Sep 2 17:43:21 2008 Subject: Crazy Question - IPv6 to IPv4 and vice versa In-Reply-To: <17838240D9A5544AAA5FF95F8D520316049038B6@ad-exh01.adhost.lan> References: <17838240D9A5544AAA5FF95F8D520316049038B6@ad-exh01.adhost.lan> Message-ID: <20080902172713.GA73836@icarus.home.lan> On Tue, Sep 02, 2008 at 10:06:12AM -0700, Michael K. Smith - Adhost wrote: > I'm wondering if it would be possible to create a mapping between an > "outside" IPv6 address and an "inside" IPv4 NAT (or round-robin group, > to take it to the next logical step) or vice versa? This would be on > a FreeBSD 7.0 installation. As a second note, if it's not supported > now would it be possible to add this support? Do you mean something like faithd(8)? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From stu at spacehopper.org Tue Sep 2 20:03:10 2008 From: stu at spacehopper.org (Stuart Henderson) Date: Tue Sep 2 20:03:23 2008 Subject: Crazy Question - IPv6 to IPv4 and vice versa In-Reply-To: <17838240D9A5544AAA5FF95F8D520316049038B6@ad-exh01.adhost.lan> References: <17838240D9A5544AAA5FF95F8D520316049038B6@ad-exh01.adhost.lan> Message-ID: <20080902200304.GH32201@pyxis.spacehopper.org> On 2008/09/02 10:06, Michael K. Smith - Adhost wrote: > I'm wondering if it would be possible to create a mapping between > an "outside" IPv6 address and an "inside" IPv4 NAT (or round-robin > group, to take it to the next logical step) or vice versa? This > would be on a FreeBSD 7.0 installation. As a second note, if it's > not supported now would it be possible to add this support? it's not possible in-kernel but on OpenBSD this is now supported in userland by relayd. There's an article about it on undeadly.org, http://undeadly.org/cgi?action=article&sid=20080724184757 however I don't know if PF on FreeBSD is at a level that can support this. From spomerg at cwu.EDU Tue Sep 2 22:04:32 2008 From: spomerg at cwu.EDU (Gavin Spomer) Date: Tue Sep 2 22:04:39 2008 Subject: PF is blocking inbound/outbound ssh, nothing else Message-ID: <48BD4A72020000900001CC0D@hermes.cwu.edu> I've recently had to leave my firewall off on my test server because when I'm ssh-ed in and enable pf, I get "locked out". :( It was working fine before and the only change that's happened recently is our university has a new ip range, but I've changed that in my config. I also have a production FreeBSD server of which I can ssh to (thankfully) with pf enabled and it's pf.conf is virtually the same. My pf config relevant to this is: #### LISTS/MACROS: ext_if = "bce0" #### TABLES: table const { campus ip range omitted } #### OPTIONS: set skip on lo0 #### NORMALIZATION: scrub in all #### FILTERING: # default deny everything in and log block in log on $ext_if all block out log on $ext_if all # activate spoofing antispoof log quick for $ext_if inet # ssh for pass in on $ext_if proto tcp from to $ext_if port 22 flags S/SA keep state (other rules for other services/ports that are working go here) # let stuff out pass out on $ext_if proto { tcp, udp } from any to any keep state /var/log/messages shows entries like: Sep 2 10:02:27 myserver sshd[21000]: fatal: Write failed: Operation not permitted tcpdump -n -e -ttt -r /var/log/pflog shows entries like: 32. 022410 rule 0/0(match): block in on bce0: mymacip.50186 > myserverip.22: P 1:97(96) ack 0 win 65535 and: 2143. 098222 rule 1/0(match): block out on bce0: myserverip.22 > mymacip.50542: P 3200122721 :3200122817(96) ack 2819997173 win 8326 My Mac is within the defined in my tables section. Only ssh is being blocked. Other things like port 80 for apache, port 3306 for MySQL, port 8080 for Plone, etc. are all fine. I have searched the freebsd-pf list archives, but it only allows me one page of search results for some reason. I have also Googled a bit and have finally posted here. Very confused. Gavin Spomer Systems Programmer Brooks Library Central Washington University From linimon at FreeBSD.org Tue Sep 2 22:34:24 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Sep 2 22:34:36 2008 Subject: kern/127042: [pf] [patch] pf recursion panic if interface group is the same as the new interface name Message-ID: <200809022234.m82MYOi8099096@freefall.freebsd.org> Old Synopsis: [PATCH] pf recursion panic if interface group is the same as the new interface name New Synopsis: [pf] [patch] pf recursion panic if interface group is the same as the new interface name Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Tue Sep 2 22:34:07 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127042 From koitsu at FreeBSD.org Tue Sep 2 23:23:19 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Sep 2 23:23:26 2008 Subject: PF is blocking inbound/outbound ssh, nothing else In-Reply-To: <48BD4A72020000900001CC0D@hermes.cwu.edu> References: <48BD4A72020000900001CC0D@hermes.cwu.edu> Message-ID: <20080902232318.GA80242@icarus.home.lan> On Tue, Sep 02, 2008 at 02:15:14PM -0700, Gavin Spomer wrote: > I've recently had to leave my firewall off on my test server because when I'm ssh-ed in and enable pf, I get "locked out". :( It was working fine before and the only change that's happened recently is our university has a new ip range, but I've changed that in my config. I also have a production FreeBSD server of which I can ssh to (thankfully) with pf enabled and it's pf.conf is virtually the same. > > My pf config relevant to this is: > > #### LISTS/MACROS: > ext_if = "bce0" > > #### TABLES: > table const { campus ip range omitted } > > #### OPTIONS: > set skip on lo0 > > #### NORMALIZATION: > scrub in all > > #### FILTERING: > # default deny everything in and log > block in log on $ext_if all > block out log on $ext_if all > > # activate spoofing > antispoof log quick for $ext_if inet > > # ssh for > pass in on $ext_if proto tcp from to $ext_if port 22 flags S/SA keep state > > (other rules for other services/ports that are working go here) > > # let stuff out > pass out on $ext_if proto { tcp, udp } from any to any keep state > > /var/log/messages shows entries like: > > Sep 2 10:02:27 myserver sshd[21000]: fatal: Write failed: Operation not permitted > > tcpdump -n -e -ttt -r /var/log/pflog shows entries like: > > 32. 022410 rule 0/0(match): block in on bce0: mymacip.50186 > myserverip.22: P 1:97(96) ack 0 win 65535 > > and: > > 2143. 098222 rule 1/0(match): block out on bce0: myserverip.22 > mymacip.50542: P 3200122721 :3200122817(96) ack 2819997173 win 8326 > > My Mac is within the defined in my tables section. Only ssh is being blocked. Other things like port 80 for apache, port 3306 for MySQL, port 8080 for Plone, etc. are all fine. > > I have searched the freebsd-pf list archives, but it only allows me one page of search results for some reason. I have also Googled a bit and have finally posted here. Very confused. The version of FreeBSD you're using is important here. What version? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From spomerg at cwu.EDU Wed Sep 3 01:08:13 2008 From: spomerg at cwu.EDU (Gavin Spomer) Date: Wed Sep 3 01:08:19 2008 Subject: PF is blocking inbound/outbound ssh, nothing else Message-ID: <48BD8108020000900001CC4B@hermes.cwu.edu> >>> Jeremy Chadwick 09/02/08 4:23 PM >>> > > The version of FreeBSD you're using is important here. What version? > > > > -- > > | Jeremy Chadwick Thanks Jeremy. It is 7.0-STABLE. How does the version make a difference? I'd like to know; every bit of added learning is a plus for me. :) - Gavin From spomerg at cwu.EDU Wed Sep 3 01:19:49 2008 From: spomerg at cwu.EDU (Gavin Spomer) Date: Wed Sep 3 01:19:55 2008 Subject: PF is blocking inbound/outbound ssh, nothing else Message-ID: <48BD83BF020000900001CC53@hermes.cwu.edu> >>> Alex Trull 09/02/08 3:22 PM >>> > > Gavin, > > > > Could mean you've maxed out your connection states pf > > > > if you've got a default amount of states, that means a 10k > > state limit - check the output of the following for the > > current states: > > > > pfctl -s all | grep current > > > > if it's at 10k or thereabouts, raise it :) Thanks Alex. It says current entries is 0. What does that mean? > > set limit { states 20000 } > > > > obviously, 20000 may still be too small, see how it scales > > once you've raised the limits. I tried setting it all the way to 100000. Still no change. > > > > You may also have run out of source ports, but that is > > another kettle of fish. What do you mean by that? If this part is not relevant to this list, could you please email off-list, maybe point me in the right direction? If you are referring to tcp/udp ports, I am running a LOT of stuff on this server! > > -- > > Alex Obviously I'm still quite the newb to pf, so I'll look at some more info... do my homework. The "pfctl -s all" is a great tip. Thanks. Looks like lots of good info there, just need to figure out what it all means. :) - Gavin From max at love2party.net Wed Sep 3 02:08:21 2008 From: max at love2party.net (Max Laier) Date: Wed Sep 3 02:08:30 2008 Subject: PF is blocking inbound/outbound ssh, nothing else In-Reply-To: <48BD4A72020000900001CC0D@hermes.cwu.edu> References: <48BD4A72020000900001CC0D@hermes.cwu.edu> Message-ID: <200809030408.15840.max@love2party.net> On Tuesday 02 September 2008 23:15:14 Gavin Spomer wrote: > I've recently had to leave my firewall off on my test server because when > I'm ssh-ed in and enable pf, I get "locked out". :( It was working fine Are you saying that you can't connect to the box once you enable pf or that the session that was used to issue the "pfctl -e" command dies? The latter is a well-known and - I believe - well-documented problem which stems from the way how pf handles tcp-states. In short: You have an active tcp connection to your sshd, once you enable pf the packets for that connection will be dropped by pf as they 1) don't match an active state and 2) [since the connection is ongoing] don't match the "flags S/SA" setting on your rule either. Even if you remove the "flags S/SA" part you will get in trouble if you use window scaling. > before and the only change that's happened recently is our university has a > new ip range, but I've changed that in my config. I also have a production > FreeBSD server of which I can ssh to (thankfully) with pf enabled and it's > pf.conf is virtually the same. > > My pf config relevant to this is: > > #### LISTS/MACROS: > ext_if = "bce0" > > #### TABLES: > table const { campus ip range omitted } > > #### OPTIONS: > set skip on lo0 > > #### NORMALIZATION: > scrub in all > > #### FILTERING: > # default deny everything in and log > block in log on $ext_if all > block out log on $ext_if all > > # activate spoofing > antispoof log quick for $ext_if inet > > # ssh for > pass in on $ext_if proto tcp from to $ext_if port 22 > flags S/SA keep state > > (other rules for other services/ports that are working go here) > > # let stuff out > pass out on $ext_if proto { tcp, udp } from any to any keep state > > /var/log/messages shows entries like: > > Sep 2 10:02:27 myserver sshd[21000]: fatal: Write failed: Operation not > permitted > > tcpdump -n -e -ttt -r /var/log/pflog shows entries like: > > 32. 022410 rule 0/0(match): block in on bce0: mymacip.50186 > > myserverip.22: P 1:97(96) ack 0 win 65535 4199243883> > > and: > > 2143. 098222 rule 1/0(match): block out on bce0: myserverip.22 > > mymacip.50542: P 3200122721 :3200122817(96) ack 2819997173 win 8326 > > > My Mac is within the defined in my tables section. Only ssh > is being blocked. Other things like port 80 for apache, port 3306 for > MySQL, port 8080 for Plone, etc. are all fine. > > I have searched the freebsd-pf list archives, but it only allows me one > page of search results for some reason. I have also Googled a bit and have > finally posted here. Very confused. > > Gavin Spomer > Systems Programmer > Brooks Library > Central Washington University > > _______________________________________________ > 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" -- /"\ 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 lance at theouterdarkness.com Wed Sep 3 02:27:46 2008 From: lance at theouterdarkness.com (Lance Murdock) Date: Wed Sep 3 02:27:54 2008 Subject: ALTQ & Multiple Connections Message-ID: <20080903020843.GA70612@theouterdarkness.com> Hello, I have two Internet connections on my firewall, and a busy web server. They are both "burstable" connections, where the commit rate is much lower than the maximum connection speed. I pay a flat rate up to the commit rate, but If I go over, I get charged per mbit. One of the connections' overage rate is a lot cheaper than the other. So, what I would like to do is fill up the first connection right up to its commit rate and then dump all remaining traffic to the second connection, thus guaranteeing myself the cheapest bill at the end of the month. With ALTQ, I can see how to limit outgoing bandwidth by dropping packets, but I don't want to drop the packets, I want to force them out the other interface, as I might with pf's route-to. Is this possible with pf and ALTQ? Thanks, Lance From max at love2party.net Wed Sep 3 02:44:34 2008 From: max at love2party.net (Max Laier) Date: Wed Sep 3 02:44:41 2008 Subject: ALTQ & Multiple Connections In-Reply-To: <20080903020843.GA70612@theouterdarkness.com> References: <20080903020843.GA70612@theouterdarkness.com> Message-ID: <200809030444.31690.max@love2party.net> On Wednesday 03 September 2008 04:08:43 Lance Murdock wrote: > I have two Internet connections on my firewall, and a busy web server. > They are both "burstable" connections, where the commit rate is much > lower than the maximum connection speed. I pay a flat rate > up to the commit rate, but If I go over, I get charged per mbit. > > One of the connections' overage rate is a lot cheaper than the other. > So, what I would like to do is fill up the first connection right up to > its commit rate and then dump all remaining traffic to the second > connection, thus guaranteeing myself the cheapest bill at the end of > the month. > > With ALTQ, I can see how to limit outgoing bandwidth by dropping packets, > but I don't want to drop the packets, I want to force them out the > other interface, as I might with pf's route-to. > > Is this possible with pf and ALTQ? No and I don't know of any software that would make that possible - probably because it's a horrible idea. You will run into all kinds of trouble with out of order packets. Let alone the issues you will have if any of your ISPs does source filtering, or with asymmetric return paths and possibly NAT. There really is no way to do what you have in mind. The only thing you can do is some level of *per-flow* round-robin (with weights) onto your outgoing connections - maybe adjusting the weights according to ALTQ usage stats. But that's a very rough estimate - but you can't do better than that, anyways. -- /"\ 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 lance at theouterdarkness.com Wed Sep 3 05:39:22 2008 From: lance at theouterdarkness.com (Lance Murdock) Date: Wed Sep 3 05:39:30 2008 Subject: ALTQ & Multiple Connections In-Reply-To: <200809030444.31690.max@love2party.net> References: <20080903020843.GA70612@theouterdarkness.com> <200809030444.31690.max@love2party.net> Message-ID: <20080903053916.GA81677@theouterdarkness.com> On Wed, Sep 03, 2008 at 04:44:31AM +0200, Max Laier wrote: > No and I don't know of any software that would make that > possible - probably because it's a horrible idea. I wouldn't say it is a horrible idea. It may have some implementation details, but the idea of maximally utilizing available resources at minimum cost is not fundamentally horrible. Also, this is for negotiation purposes as much as any technical reason. Our carriers feel there is no need to negotiate on price because they're going to get paid on the overages anyway. They figure the router and construction expenses of pulling in more fiber are pretty much a lock-in, and they're pretty much right. So I'd like to put a shot across their bow that not only do we have the power to control how much they get paid without scuttling our own site, but also we don't need to pull more fiber to do it. :-) > You will run into all kinds of trouble with out > of order packets. Let alone the issues you will have if any of > your ISPs does source filtering, or with asymmetric return paths > and possibly NAT. Source filtering and NAT are not in play here and the two endpoints are not identical but they are topologically very close so asymmetric routing impact should be minimal, especially for short-lived web connections. But yes, I can see that "sticky" behavior on a per-flow basis would be essential. Ideally we would let as much traffic as possible take its best path according to the route table and only shape the minimum necessary to meet our utilization objectives. But even I am confident I have crossed irretrievably into fantasyland at that point. I'm thinking of something along the lines of good old fashioned multilink PPP, which brought up more channels based on utilization. The only difference here is that we're not going to get protocol cooperation from the far end. > The only thing you can do is > some level of *per-flow* round-robin (with weights) onto your outgoing > connections - maybe adjusting the weights according to ALTQ usage stats. I'm sorry, I don't know enough about ALTQ to know if this is intended to be a practical suggestion. If so, where would I look for documentation? I've got the Reed book and it's been massively helpful but doesn't appear to cover the sort of crazy misuse that I have in mind. > But > that's a very rough estimate - but you can't do better than that, anyways. If we can get within, say, 10% that would be a great start. Since carrier standard is 95/5 billing, all we have to do is visibly clip the peaks on an MRTG graph to achieve our objective. Thanks, Lance From mohacsi at niif.hu Wed Sep 3 06:30:47 2008 From: mohacsi at niif.hu (Mohacsi Janos) Date: Wed Sep 3 06:30:54 2008 Subject: Crazy Question - IPv6 to IPv4 and vice versa In-Reply-To: <17838240D9A5544AAA5FF95F8D520316049038B6@ad-exh01.adhost.lan> References: <17838240D9A5544AAA5FF95F8D520316049038B6@ad-exh01.adhost.lan> Message-ID: <20080903082619.U4624@mignon.ki.iif.hu> On Tue, 2 Sep 2008, Michael K. Smith - Adhost wrote: > Hello All: > > I'm wondering if it would be possible to create a mapping between an > "outside" IPv6 address and an "inside" IPv4 NAT (or round-robin group, > to take it to the next logical step) or vice versa? This would be on a > FreeBSD 7.0 installation. As a second note, if it's not supported now > would it be possible to add this support? > > Regards, > > Mike use some kind of translator: 1. NAT-PT - however depracated - and not maintained the *BSD version anymore: http://mucc.mahidol.ac.th/~ccvvs/natpt-setup.html> 2. TRT - faithd(8) - TCP only 3. proxy - netcat, apache, squid etc. - might be specific to application Regards, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 > > -- > Michael K. Smith - CISSP, GISP > Chief Technical Officer - Adhost Internet LLC > mksmith@adhost.com > w: +1 (206) 404-9500 f: +1 (206) 404-9050 > PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > > From koitsu at FreeBSD.org Wed Sep 3 07:04:43 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Sep 3 07:04:49 2008 Subject: ALTQ & Multiple Connections In-Reply-To: <20080903053916.GA81677@theouterdarkness.com> References: <20080903020843.GA70612@theouterdarkness.com> <200809030444.31690.max@love2party.net> <20080903053916.GA81677@theouterdarkness.com> Message-ID: <20080903070440.GA28260@icarus.home.lan> On Tue, Sep 02, 2008 at 10:39:16PM -0700, Lance Murdock wrote: > On Wed, Sep 03, 2008 at 04:44:31AM +0200, Max Laier wrote: > > No and I don't know of any software that would make that > > possible - probably because it's a horrible idea. > > I wouldn't say it is a horrible idea. It may have some implementation > details, but the idea of maximally utilizing available resources at > minimum cost is not fundamentally horrible. > > Also, this is for negotiation purposes as much as any technical reason. > Our carriers feel there is no need to negotiate on price because they're > going to get paid on the overages anyway. They figure the router and > construction expenses of pulling in more fiber are pretty much a lock-in, > and they're pretty much right. So I'd like to put a shot across > their bow that not only do we have the power to control how much they > get paid without scuttling our own site, but also we don't need to pull > more fiber to do it. :-) If I understand your situation correctly, you pay for a connection to two different peering providers or LECs, and the bandwidth (likely 95th-percentile) that you're billed against is different per provider (e.g. Provider ABC gives you a gigE port with 4mbit/sec 95th-percentile for X dollars a month, while provider XYZ gives you a gigE port with 512kbit/sec 95th-percentile for X dollars a month). Is this correct? If so, I'm not even sure commercial routers (e.g. Junipers) can solve your predicament. Ideally you'd be better off with symmetric bandwidth amounts to both of your peers (e.g. you pay both Provider ABC and Provider XYZ for 4mbit/95th of traffic). In that situation, you might be able to used a "load-balanced" solution for packets, which *might* work and meet your needs. I say "might" because Internet routing does not guarantee you'll be using both connections 50/50. I'm not sure why people think that; it really doesn't work that way in practise. Assuming the two ISPs are different and you have different IPs per peer, you're screwed. BGP preferencing and route priority will ensure you probably will not utilise each connection equally. My comment applies to incoming traffic, not outbound. Outbound you can preference/balance at your leisure, as Max described. > Ideally we would let as much traffic as possible take its best path > according to the route table and only shape the minimum necessary > to meet our utilization objectives. But even I am confident I have > crossed irretrievably into fantasyland at that point. Like I said: why do you think the rest of the world will adhere to what your routing table prefers? This is one of the common caveats to BGP. Just because you preference a route through provider ABC doesn't mean some ISP in Malaysia is going to honour that preference. I deal with this situation at my day job on a daily basis. > I'm thinking of something along the lines of good old fashioned > multilink PPP, which brought up more channels based on utilization. > The only difference here is that we're not going to get protocol > cooperation from the far end. Okay, so multilink PPP implies that you're able to get at least some sort of common IP block assigned to you through both peers, and get both peers to comply with your routing policies? Let me know if you manage to do that, as I'd be interesting in knowing what providers are *that* flexible. > > The only thing you can do is > > some level of *per-flow* round-robin (with weights) onto your outgoing > > connections - maybe adjusting the weights according to ALTQ usage stats. > > I'm sorry, I don't know enough about ALTQ to know if this is intended to > be a practical suggestion. If so, where would I look for documentation? > I've got the Reed book and it's been massively helpful but doesn't > appear to cover the sort of crazy misuse that I have in mind. > > > But > > that's a very rough estimate - but you can't do better than that, anyways. > > If we can get within, say, 10% that would be a great start. Since carrier > standard is 95/5 billing, all we have to do is visibly clip the peaks on > an MRTG graph to achieve our objective. See above. I'm pretty sure I understand your predicament, and if I was in your shoes, I'd be dropping my contract with the provider who provides less bandwidth (or costs more) and urging the other provider to provide more reliable redundancy and peering. I've personally been in that situation, though with only one provider used at the time. We pulled our entire infrastructure out of their datacenter one we found out they had no form of switch or router failover/redundancy, and that despite being in California, they were using Telia (a Swedish ISP) to peer with large carriers like AT&T and MCI. Telia connection dies? No failover available, and Telia has no NOC in the US. "Hallo dis Telia NOC" "Talar du Engelska?" "Nej" -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From guido at gvr.org Wed Sep 3 11:28:53 2008 From: guido at gvr.org (Guido van Rooij) Date: Wed Sep 3 11:29:01 2008 Subject: keeping state on outgoing connections fails (?) Message-ID: <20080903110943.GA25396@gvr.gvr.org> Setup: FreeBSD 6.3 system with 2 interfaces: ep0 and bge0. ep0: 1.2.3.4/24 bge0: 10.0.0.1/24 ruleset (made as simple as possible): pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 block drop out log quick on ep0 all pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state When I telnet from 1.2.3.1 to 10.0.0.2, the packet comes in via ep0 and passes because of rule 1. Then the packet goes out via bge0, is passed via rule 3 and a satte entry is created. The return SYN/ACK comes in via bge0 and passes because of the state entry. Then the packet should be sent out via ep0, but it is blocked, as pflogd shows: 000000 rule 1/0(match): block out on ep0: 10.0.0.2.25 > 1.2.3.1.1040: S 3255603624:3255603624(0) ack 3600825196 win 65535 2. 955997 rule 1/0(match): block out on ep0: 10.0.0.2.25 > 1.2.3.1.1040: S 3255603624:3255603624(0) ack 3600825196 win 65535 2. 999812 rule 1/0(match): block out on ep0: 10.0.0.2.25 > 1.2.3.1.1040: S 3255603624:3255603624(0) ack 3600825196 win 65535 3. 009226 rule 1/0(match): block out on ep0: 10.0.0.2.25 > 1.2.3.1.1040: S 3255603624:3255603624(0) ack 3600825196 win 65535 5. 999234 rule 1/0(match): block out on ep0: 10.0.0.2.25 > 1.2.3.1.1040: S 3255603624:3255603624(0) ack 3600825196 win 65535 A tcpdump of the relevant packets (bad checksum because of chaecksum ofloading): 13:05:39.471200 IP (tos 0x0, ttl 127, id 195, offset 0, flags [DF], proto: TCP (6), length: 48, bad cksum 0 (->ed00)!) 1.2.3.1.1040 > 10.0.0.2.25: S, cksum 0x62e5 (correct), 3600825195:3600825195(0) win 64512 13:05:39.471378 IP (tos 0x0, ttl 64, id 37525, offset 0, flags [DF], proto: TCP (6), length: 48) 10.0.0.2.25 > 1.2.3.1.1040: S, cksum 0x0c21 (correct), 3255603624:3255603624(0) ack 3600825196 win 65535 13:05:42.427163 IP (tos 0x0, ttl 127, id 196, offset 0, flags [DF], proto: TCP (6), length: 48, bad cksum 0 (->ecff)!) 1.2.3.1.1040 > 10.0.0.2.25: S, cksum 0x62e5 (correct), 3600825195:3600825195(0) win 64512 13:05:42.427377 IP (tos 0x0, ttl 64, id 37593, offset 0, flags [none], proto: TCP (6), length: 48) 10.0.0.2.25 > 1.2.3.1.1040: S, cksum 0x0c21 (correct), 3255603624:3255603624(0) ack 3600825196 win 65535 13:05:45.427182 IP (tos 0x0, ttl 64, id 39074, offset 0, flags [none], proto: TCP (6), length: 48) 10.0.0.2.25 > 1.2.3.1.1040: S, cksum 0x0c21 (correct), 3255603624:3255603624(0) ack 3600825196 win 65535 13:05:48.436285 IP (tos 0x0, ttl 127, id 197, offset 0, flags [DF], proto: TCP (6), length: 48, bad cksum 0 (->ecfe)!) 1.2.3.1.1040 > 10.0.0.2.25: S, cksum 0x62e5 (correct), 3600825195:3600825195(0) win 64512 13:05:48.436418 IP (tos 0x0, ttl 64, id 45408, offset 0, flags [none], proto: TCP (6), length: 48) 10.0.0.2.25 > 1.2.3.1.1040: S, cksum 0x0c21 (correct), 3255603624:3255603624(0) ack 3600825196 win 65535 13:05:54.435645 IP (tos 0x0, ttl 64, id 48287, offset 0, flags [none], proto: TCP (6), length: 48) 10.0.0.2.25 > 1.2.3.1.1040: S, cksum 0x0c21 (correct), 3255603624:3255603624(0) ack 3600825196 win 65535 pfctl -si before telnetting: State Table Total Rate current entries 0 searches 0 0.0/s inserts 0 0.0/s removals 0 0.0/s Counters match 0 0.0/s bad-offset 0 0.0/s fragment 0 0.0/s short 0 0.0/s normalize 0 0.0/s memory 0 0.0/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 0 0.0/s proto-cksum 0 0.0/s state-mismatch 0 0.0/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 0 0.0/s synproxy 0 0.0/s After telnetting: State Table Total Rate current entries 1 searches 44 1.8/s inserts 1 0.0/s removals 0 0.0/s Counters match 32 1.3/s bad-offset 0 0.0/s fragment 0 0.0/s short 0 0.0/s normalize 0 0.0/s memory 0 0.0/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 0 0.0/s proto-cksum 0 0.0/s state-mismatch 0 0.0/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 0 0.0/s synproxy 0 0.0/s The state entry (pfctl -vvvs state): self tcp 1.2.3.1:1040 -> 10.0.0.2:25 ESTABLISHED:SYN_SENT [3600825196 + 65535] [3255603625 + 64512] age 00:00:22, expires in 00:00:23, 8:5 pkts, 424:240 bytes, rule 2 id: 48be58f800000009 creatorid: 89adbe9b pfctl -vvvvs rules before the telnet: @0 pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] @1 block drop out log quick on ep0 all [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] @2 pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] and after: @0 pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 [ Evaluations: 32 Packets: 3 Bytes: 144 States: 0 ] @1 block drop out log quick on ep0 all [ Evaluations: 5 Packets: 5 Bytes: 240 States: 0 ] @2 pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state [ Evaluations: 24 Packets: 13 Bytes: 664 States: 1 ] I would expect the packet to match the state entry, but somehow it does not. Setting the state-policy to if-bound or floating makes no difference. My question is why the packet does not match the state entry resulting to its blocking. -Guido From guido at gvr.org Wed Sep 3 12:54:08 2008 From: guido at gvr.org (Guido van Rooij) Date: Wed Sep 3 12:54:14 2008 Subject: keeping state on outgoing connections fails (?) In-Reply-To: <48BE864C.6000006@radel.com> References: <20080903110943.GA25396@gvr.gvr.org> <48BE864C.6000006@radel.com> Message-ID: <20080903125407.GA27232@gvr.gvr.org> On Wed, Sep 03, 2008 at 08:42:52AM -0400, Jon Radel wrote: > Guido van Rooij wrote: > > > > Setup: FreeBSD 6.3 system with 2 interfaces: ep0 and bge0. > > > > ep0: 1.2.3.4/24 > > bge0: 10.0.0.1/24 > > > > ruleset (made as simple as possible): > > pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 > > block drop out log quick on ep0 all > > pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state > > > > When I telnet from 1.2.3.1 to 10.0.0.2, the packet comes in via ep0 > > and passes because of rule 1. > > Then the packet goes out via bge0, is passed via rule 3 and a satte entry is > > created. > > > > The return SYN/ACK comes in via bge0 and passes because of the state entry. > > > > Then the packet should be sent out via ep0, but it is blocked, as pflogd shows: > > And does the problem go away when you put a "keep state" at the end of > line 1? > I don't know. Due to the nature of the setup, that is not an option (like I posted in the original mail, this is a very simplistic ruleset; the real life situation will be a 5-interface setup with a lot more complexity. Being able to set state on outgoing packets is crucial). I did test the folowing ruleset: pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 keep state block drop out log quick on ep0 all pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 And there it works, but doesn't solve my problem unfrotunately. -Guido From jon at radel.com Wed Sep 3 13:25:25 2008 From: jon at radel.com (Jon Radel) Date: Wed Sep 3 13:25:31 2008 Subject: keeping state on outgoing connections fails (?) In-Reply-To: <20080903125407.GA27232@gvr.gvr.org> References: <20080903110943.GA25396@gvr.gvr.org> <48BE864C.6000006@radel.com> <20080903125407.GA27232@gvr.gvr.org> Message-ID: <48BE9038.8020303@radel.com> Guido van Rooij wrote: > On Wed, Sep 03, 2008 at 08:42:52AM -0400, Jon Radel wrote: >> Guido van Rooij wrote: >>> Setup: FreeBSD 6.3 system with 2 interfaces: ep0 and bge0. >>> >>> ep0: 1.2.3.4/24 >>> bge0: 10.0.0.1/24 >>> >>> ruleset (made as simple as possible): >>> pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 >>> block drop out log quick on ep0 all >>> pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state >>> >>> When I telnet from 1.2.3.1 to 10.0.0.2, the packet comes in via ep0 >>> and passes because of rule 1. >>> Then the packet goes out via bge0, is passed via rule 3 and a satte entry is >>> created. >>> >>> The return SYN/ACK comes in via bge0 and passes because of the state entry. >>> >>> Then the packet should be sent out via ep0, but it is blocked, as pflogd shows: >> And does the problem go away when you put a "keep state" at the end of >> line 1? >> > > I don't know. Due to the nature of the setup, that is not an option (like > I posted in the original mail, this is a very simplistic ruleset; the > real life situation will be a 5-interface setup with a lot more > complexity. Being able to set state on outgoing packets is crucial). > > I did test the folowing ruleset: > pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 keep state > block drop out log quick on ep0 all > pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 > > And there it works, but doesn't solve my problem unfrotunately. And why doesn't it solve your problem? You really are going to have to either keep state on ep0 or allow everything that's legal in "pass out on ep0" statements. For example: block all pass in on ep0 inet from 1.2.3.1 to 10.0.0.2 pass out on ep0 inet from 10.0.0.2 to 1.2.3.1 pass out on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state --Jon Radel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3283 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20080903/bc06e717/smime.bin From jon at radel.com Wed Sep 3 13:43:10 2008 From: jon at radel.com (Jon Radel) Date: Wed Sep 3 13:43:16 2008 Subject: keeping state on outgoing connections fails (?) In-Reply-To: <20080903110943.GA25396@gvr.gvr.org> References: <20080903110943.GA25396@gvr.gvr.org> Message-ID: <48BE864C.6000006@radel.com> Guido van Rooij wrote: > > Setup: FreeBSD 6.3 system with 2 interfaces: ep0 and bge0. > > ep0: 1.2.3.4/24 > bge0: 10.0.0.1/24 > > ruleset (made as simple as possible): > pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 > block drop out log quick on ep0 all > pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state > > When I telnet from 1.2.3.1 to 10.0.0.2, the packet comes in via ep0 > and passes because of rule 1. > Then the packet goes out via bge0, is passed via rule 3 and a satte entry is > created. > > The return SYN/ACK comes in via bge0 and passes because of the state entry. > > Then the packet should be sent out via ep0, but it is blocked, as pflogd shows: And does the problem go away when you put a "keep state" at the end of line 1? --Jon Radel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3283 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20080903/5ab0d7ab/smime.bin From guido at gvr.org Wed Sep 3 13:52:05 2008 From: guido at gvr.org (Guido van Rooij) Date: Wed Sep 3 13:52:12 2008 Subject: keeping state on outgoing connections fails (?) In-Reply-To: <48BE9038.8020303@radel.com> References: <20080903110943.GA25396@gvr.gvr.org> <48BE864C.6000006@radel.com> <20080903125407.GA27232@gvr.gvr.org> <48BE9038.8020303@radel.com> Message-ID: <20080903135204.GA28111@gvr.gvr.org> On Wed, Sep 03, 2008 at 09:25:12AM -0400, Jon Radel wrote: > > > > I did test the folowing ruleset: > > pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 keep state > > block drop out log quick on ep0 all > > pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 > > > > And there it works, but doesn't solve my problem unfrotunately. > > And why doesn't it solve your problem? > > You really are going to have to either keep state on ep0 or allow > everything that's legal in "pass out on ep0" statements. > > For example: > > block all > pass in on ep0 inet from 1.2.3.1 to 10.0.0.2 > pass out on ep0 inet from 10.0.0.2 to 1.2.3.1 > pass out on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state > And why is that so? This bascially rules out keep state on outgouing packets on any router-type system. That seems like an unnecessary limitation. I have not yet heart any reason why this is the case. pf was modelled after ipf, so I wonder why this change in state handling was introduced. -Guido From jon at radel.com Wed Sep 3 14:13:25 2008 From: jon at radel.com (Jon Radel) Date: Wed Sep 3 14:13:31 2008 Subject: keeping state on outgoing connections fails (?) In-Reply-To: <20080903135204.GA28111@gvr.gvr.org> References: <20080903110943.GA25396@gvr.gvr.org> <48BE864C.6000006@radel.com> <20080903125407.GA27232@gvr.gvr.org> <48BE9038.8020303@radel.com> <20080903135204.GA28111@gvr.gvr.org> Message-ID: <48BE9B74.90404@radel.com> Guido van Rooij wrote: > On Wed, Sep 03, 2008 at 09:25:12AM -0400, Jon Radel wrote: >>> I did test the folowing ruleset: >>> pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 keep state >>> block drop out log quick on ep0 all >>> pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 >>> >>> And there it works, but doesn't solve my problem unfrotunately. >> And why doesn't it solve your problem? >> >> You really are going to have to either keep state on ep0 or allow >> everything that's legal in "pass out on ep0" statements. >> >> For example: >> >> block all >> pass in on ep0 inet from 1.2.3.1 to 10.0.0.2 >> pass out on ep0 inet from 10.0.0.2 to 1.2.3.1 >> pass out on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state >> > > And why is that so? This bascially rules out keep state on outgouing packets > on any router-type system. That seems like an unnecessary limitation. What? If you want state, turn it on: block all pass in on ep0 inet from 1.2.3.1 to 10.0.0.2 keep state pass out on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state should work fine also. Other things being equal (in other words, your mileage may vary....), that is both more secure and more efficient than the first rule set I offered as an example. I sent the first one only because you insisted that your real rule set for 5 interfaces would not allow you to maintain state on ep0 (or its equivalent). You still haven't given us any hints as to why the solution which maintains state on all interfaces is impossible for you. > > I have not yet heart any reason why this is the case. pf was modelled > after ipf, so I wonder why this change in state handling was introduced. This is probably the wrong list if you want to have people justify design decisions. --Jon Radel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3283 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20080903/756dbd77/smime.bin From guido at gvr.org Wed Sep 3 14:42:39 2008 From: guido at gvr.org (Guido van Rooij) Date: Wed Sep 3 14:42:46 2008 Subject: keeping state on outgoing connections fails (?) In-Reply-To: <48BE9B74.90404@radel.com> References: <20080903110943.GA25396@gvr.gvr.org> <48BE864C.6000006@radel.com> <20080903125407.GA27232@gvr.gvr.org> <48BE9038.8020303@radel.com> <20080903135204.GA28111@gvr.gvr.org> <48BE9B74.90404@radel.com> Message-ID: <20080903144237.GA28697@gvr.gvr.org> On Wed, Sep 03, 2008 at 10:13:08AM -0400, Jon Radel wrote: > > And why is that so? This bascially rules out keep state on outgouing packets > > on any router-type system. That seems like an unnecessary limitation. > > What? If you want state, turn it on: > > block all > pass in on ep0 inet from 1.2.3.1 to 10.0.0.2 keep state > pass out on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state > > should work fine also. Other things being equal (in other words, your > mileage may vary....), that is both more secure and more efficient than > the first rule set I offered as an example. I sent the first one only It's certianly not more efficient as one needs twice as many state entries. > because you insisted that your real rule set for 5 interfaces would not > allow you to maintain state on ep0 (or its equivalent). Suppose I want to limit traffic to 10.0.0.2 which is behind bge0. Then when solving this with keeping state on outgoing packets on bge0 means a single rule. With your suggestion, the amount of rules is five times as big because then I need to add keep state rules for incoming packets on the other interfaces as well. > > You still haven't given us any hints as to why the solution which > maintains state on all interfaces is impossible for you. Like with the ruleset you posted, a single keep state rule is sufficient. > > > > > I have not yet heart any reason why this is the case. pf was modelled > > after ipf, so I wonder why this change in state handling was introduced. > > This is probably the wrong list if you want to have people justify > design decisions. > I honestly don't think this was a design decison, but a bug in pf. Like I said, the state engine was modelled after ipf's (hack, the whole TCP-sepcifics came from a paper I wrote), which behaves exactly similar as pf, _except_ for this specific scenario. So it shure smells like a bug. Please try to undeerstand my question: the question is not: how do I work around a failing ruleset. The question is: why doesn't it work. -Guido From guido at gvr.org Wed Sep 3 14:44:05 2008 From: guido at gvr.org (Guido van Rooij) Date: Wed Sep 3 14:44:11 2008 Subject: keeping state on outgoing connections fails (?) In-Reply-To: <9e20d71e0809030732v2d202cc5x74a33977d8d9ac64@mail.gmail.com> References: <20080903110943.GA25396@gvr.gvr.org> <48BE864C.6000006@radel.com> <20080903125407.GA27232@gvr.gvr.org> <48BE9038.8020303@radel.com> <20080903135204.GA28111@gvr.gvr.org> <48BE9B74.90404@radel.com> <9e20d71e0809030732v2d202cc5x74a33977d8d9ac64@mail.gmail.com> Message-ID: <20080903144404.GB28697@gvr.gvr.org> On Wed, Sep 03, 2008 at 05:32:25PM +0300, Artis Caune wrote: > >>>> I did test the folowing ruleset: > >>>> pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 keep state > >>>> block drop out log quick on ep0 all > >>>> pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 > > maybe "set skip on ep0" ? > Nope. There will be outgoing keep state rules on ep0. But not fro connections which are already in the state table. besides the skip would roll out all incoming rules as well. -Guido From lance at theouterdarkness.com Wed Sep 3 14:54:00 2008 From: lance at theouterdarkness.com (Lance Murdock) Date: Wed Sep 3 14:54:05 2008 Subject: ALTQ & Multiple Connections In-Reply-To: <20080903070440.GA28260@icarus.home.lan> References: <20080903020843.GA70612@theouterdarkness.com> <200809030444.31690.max@love2party.net> <20080903053916.GA81677@theouterdarkness.com> <20080903070440.GA28260@icarus.home.lan> Message-ID: <20080903145357.GA90983@theouterdarkness.com> On Wed, Sep 03, 2008 at 12:04:40AM -0700, Jeremy Chadwick wrote: > My comment applies to incoming traffic, not outbound. We have a web site. We're not even a little bit interested in shaping inbound traffic. It's 1/10th of outbound, if that, and can be entirely disregarded, as we're happy to let that traffic always take the BGP-chosen path. > Outbound you can > preference/balance at your leisure, as Max described. Right, and that's all we're trying to figure out how to do. Lance From artis.caune at gmail.com Wed Sep 3 14:55:49 2008 From: artis.caune at gmail.com (Artis Caune) Date: Wed Sep 3 14:55:56 2008 Subject: keeping state on outgoing connections fails (?) In-Reply-To: <48BE9B74.90404@radel.com> References: <20080903110943.GA25396@gvr.gvr.org> <48BE864C.6000006@radel.com> <20080903125407.GA27232@gvr.gvr.org> <48BE9038.8020303@radel.com> <20080903135204.GA28111@gvr.gvr.org> <48BE9B74.90404@radel.com> Message-ID: <9e20d71e0809030732v2d202cc5x74a33977d8d9ac64@mail.gmail.com> >>>> I did test the folowing ruleset: >>>> pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 keep state >>>> block drop out log quick on ep0 all >>>> pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 maybe "set skip on ep0" ? -- regards, Artis Caune <----. CCNA <----|==================== <----' didii FreeBSD From jon at radel.com Wed Sep 3 15:08:25 2008 From: jon at radel.com (Jon Radel) Date: Wed Sep 3 15:08:31 2008 Subject: keeping state on outgoing connections fails (?) In-Reply-To: <20080903144237.GA28697@gvr.gvr.org> References: <20080903110943.GA25396@gvr.gvr.org> <48BE864C.6000006@radel.com> <20080903125407.GA27232@gvr.gvr.org> <48BE9038.8020303@radel.com> <20080903135204.GA28111@gvr.gvr.org> <48BE9B74.90404@radel.com> <20080903144237.GA28697@gvr.gvr.org> Message-ID: <48BEA861.5050601@radel.com> Guido van Rooij wrote: > On Wed, Sep 03, 2008 at 10:13:08AM -0400, Jon Radel wrote: >>> And why is that so? This bascially rules out keep state on outgouing packets >>> on any router-type system. That seems like an unnecessary limitation. >> What? If you want state, turn it on: >> >> block all >> pass in on ep0 inet from 1.2.3.1 to 10.0.0.2 keep state >> pass out on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state >> >> should work fine also. Other things being equal (in other words, your >> mileage may vary....), that is both more secure and more efficient than >> the first rule set I offered as an example. I sent the first one only > > It's certianly not more efficient as one needs twice as many state entries. I say apples are better than oranges. You come along and say, "No, fool, pears are not better than oranges." I wish you luck with your problems. You might be happier using something other that PF. --Jon Radel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3283 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20080903/fc2ac015/smime.bin From koitsu at FreeBSD.org Wed Sep 3 15:26:34 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Sep 3 15:26:41 2008 Subject: keeping state on outgoing connections fails (?) In-Reply-To: <20080903110943.GA25396@gvr.gvr.org> References: <20080903110943.GA25396@gvr.gvr.org> Message-ID: <20080903152632.GA89687@icarus.home.lan> On Wed, Sep 03, 2008 at 01:09:43PM +0200, Guido van Rooij wrote: > > Setup: FreeBSD 6.3 system with 2 interfaces: ep0 and bge0. > > ep0: 1.2.3.4/24 > bge0: 10.0.0.1/24 > > ruleset (made as simple as possible): > pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 > block drop out log quick on ep0 all > pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state First and foremost, I'm sorry I didn't reply to this sooner -- I've been fighting with Comcast for the past ~9 hours over a "single report of me sending spam" resulting in them blocking my ability to send mail via smtp.comcast.net:25... Yeah... anyway... I'm a bit confused by these rules and your network configuration. Rule #3 is keeping state incorrectly. You need to keep state only on the initial TCP SYN. You are using RELENG_6, which means you need to specify "flags S/SA", otherwise "keep state" is going to match against all TCP packets regardless of bits (FIN, ACK, PSH, etc.), which is probably not what you want. This may be the source of your problem. Rule #1 allows any packet with a source address of 1.2.3.1, arriving on the ep0 interface, destined to 10.0.0.2. How exactly are packets arriving on ep0 (which is bound to 1.2.3.0/24) with a destination of 10.0.0.2 in the first place? That seems strange. Is your gateway on your network blindly forwarding packets between networks or something? Or is this FreeBSD box acting *as* a gateway? Rule #3 allows any outbound packet from 1.2.3.1 (which isn't even an IP address bound to bge0), arriving on the bge0 interface, destined to 1.0.0.2. I wonder if this rule is backwards (IPs in from/to should be reversed). If none of this helps, others will have to assist, as I'm out of ideas other than the above. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From peter.wullinger at googlemail.com Wed Sep 3 16:31:32 2008 From: peter.wullinger at googlemail.com (Peter Wullinger) Date: Wed Sep 3 16:31:39 2008 Subject: keeping state on outgoing connections fails (?) In-Reply-To: <20080903152632.GA89687@icarus.home.lan> References: <20080903110943.GA25396@gvr.gvr.org> <20080903152632.GA89687@icarus.home.lan> Message-ID: <20080903161759.GA2761@kaliope.home> I'll reply to Jeremy, since his answer somehow confused me. In epistula a Jeremy Chadwick, die horaque Wed Sep 3 17:26:32 2008: > On Wed, Sep 03, 2008 at 01:09:43PM +0200, Guido van Rooij wrote: > > > > Setup: FreeBSD 6.3 system with 2 interfaces: ep0 and bge0. > > > > ep0: 1.2.3.4/24 > > bge0: 10.0.0.1/24 > > > > ruleset (made as simple as possible): > > pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 > > block drop out log quick on ep0 all > > pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state At little bit of guessing led me to the (possible, I have not tested this) culprit: Is your state-policy set to "floating" or "if-bound"? >From a casual look at the log entries and traffic snapshots you have sent, this seems to be pf working in "if-bound" mode. In this case, the created state table entry matches incoming on bge0, but not on outgoing on ep0 any more (packets pass through pf twice, as expected). This still maybe a bug, but it's common to rule out all possible culprits before spreading blame. In epistula a Jeremy Chadwick, die horaque Wed Sep 3 17:26:32 2008: > I'm a bit confused by these rules and your network configuration. > Rule #1 allows any packet with a source address of 1.2.3.1, arriving on > the ep0 interface, destined to 10.0.0.2. How exactly are packets > arriving on ep0 (which is bound to 1.2.3.0/24) with a destination of > 10.0.0.2 in the first place? That seems strange. Is your gateway on > your network blindly forwarding packets between networks or something? > Or is this FreeBSD box acting *as* a gateway? It seems to be a gateway, forwarding packets. What exactly do you find strange? Have I missed something? Peter -- Listening was an art, he had developed over the years. Because if you listened long and hard enough, people would tell you more, they thought they knew. -- Terry Pratchett, Thief Of Time From pf_free at chrissmith.org Wed Sep 3 16:38:49 2008 From: pf_free at chrissmith.org (Chris Smith) Date: Wed Sep 3 16:38:57 2008 Subject: keeping state on outgoing connections fails (?) In-Reply-To: <20080903152632.GA89687@icarus.home.lan> References: <20080903110943.GA25396@gvr.gvr.org> <20080903152632.GA89687@icarus.home.lan> Message-ID: <200809031212.41979.pf_free@chrissmith.org> On Wednesday 03 September 2008 11:26:32 am Jeremy Chadwick wrote: > I've been > fighting with Comcast for the past ~9 hours over a "single report of me > sending spam" resulting in them blocking my ability to send mail via > smtp.comcast.net:25... Been there, done that (several times). They just make this shit up - really they must. As the last time they shut off my port 25 all of my mail was being sent via gmail on port 587 with my openBSD firewall blocking port 25. I hadn't used port 25 or their smtp servers for months - and I never use my comcast email address (it only receives the email they send me and forwards it to my google run account). They are totally clueless. From guido at gvr.org Wed Sep 3 18:23:03 2008 From: guido at gvr.org (Guido van Rooij) Date: Wed Sep 3 18:23:10 2008 Subject: keeping state on outgoing connections fails (?) In-Reply-To: <20080903161759.GA2761@kaliope.home> References: <20080903110943.GA25396@gvr.gvr.org> <20080903152632.GA89687@icarus.home.lan> <20080903161759.GA2761@kaliope.home> Message-ID: <20080903182301.GA31792@gvr.gvr.org> On Wed, Sep 03, 2008 at 06:17:59PM +0200, Peter Wullinger wrote: > > At little bit of guessing led me to the (possible, I have not tested > this) culprit: Is your state-policy set to "floating" or "if-bound"? I tyried both, but there is no difference. > > >From a casual look at the log entries and traffic snapshots you have sent, > this seems to be pf working in "if-bound" mode. In this case, the > created state table entry matches incoming on bge0, but not on > outgoing on ep0 any more (packets pass through pf twice, as expected). > > This still maybe a bug, but it's common to rule out all possible > culprits before spreading blame. > True, but as state is created on the outbound interface for the first packet (bge), there is no corresponding incoming interface yet. At least with ipf, the return packet would first match the recorded outgoing interface (bge). Then it follows the gateway's internal routing. When it then goes out and passes through the firewall-code, it notices it does not yet know the interface (ep0) and records it in the state entry and passes it. This makes perfect sense: when the original packet would have arrived at a different interface than bge0, there must have been some kind of spoofing and should have been blocked in the first place. -Guido From max at love2party.net Wed Sep 3 18:25:13 2008 From: max at love2party.net (Max Laier) Date: Wed Sep 3 18:25:21 2008 Subject: keeping state on outgoing connections fails (?) In-Reply-To: <20080903110943.GA25396@gvr.gvr.org> References: <20080903110943.GA25396@gvr.gvr.org> Message-ID: <200809032025.11619.max@love2party.net> On Wednesday 03 September 2008 13:09:43 Guido van Rooij wrote: > Setup: FreeBSD 6.3 system with 2 interfaces: ep0 and bge0. > > ep0: 1.2.3.4/24 > bge0: 10.0.0.1/24 > > ruleset (made as simple as possible): > pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 > block drop out log quick on ep0 all > pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state > > When I telnet from 1.2.3.1 to 10.0.0.2, the packet comes in via ep0 > and passes because of rule 1. > Then the packet goes out via bge0, is passed via rule 3 and a satte entry > is created. > > The return SYN/ACK comes in via bge0 and passes because of the state entry. > > Then the packet should be sent out via ep0, but it is blocked, as pflogd > shows: 000000 rule 1/0(match): block out on ep0: 10.0.0.2.25 > There is no state entry and no rule that would allow traffic to be sent out via ep0. You either have to create state on ep0 or you must allow traffic on ep0 in both directions. I think the ruleset you are looking for is something along the lines of: block drop all pass in on ep0 inet from 1.2.3.1 to 10.0.0.2 keep state flags S/SA pass out on bge0 inet from 1.2.3.1 to 10.0.0.2 keep state flags S/SA -- /"\ 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 jon at radel.com Wed Sep 3 18:42:25 2008 From: jon at radel.com (Jon Radel) Date: Wed Sep 3 18:42:38 2008 Subject: keeping state on outgoing connections fails (?) In-Reply-To: <200809032025.11619.max@love2party.net> References: <20080903110943.GA25396@gvr.gvr.org> <200809032025.11619.max@love2party.net> Message-ID: <48BEDA83.80600@radel.com> Max Laier wrote: > On Wednesday 03 September 2008 13:09:43 Guido van Rooij wrote: >> Setup: FreeBSD 6.3 system with 2 interfaces: ep0 and bge0. >> >> ep0: 1.2.3.4/24 >> bge0: 10.0.0.1/24 >> >> ruleset (made as simple as possible): >> pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 >> block drop out log quick on ep0 all >> pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state >> >> When I telnet from 1.2.3.1 to 10.0.0.2, the packet comes in via ep0 >> and passes because of rule 1. >> Then the packet goes out via bge0, is passed via rule 3 and a satte entry >> is created. >> >> The return SYN/ACK comes in via bge0 and passes because of the state entry. >> >> Then the packet should be sent out via ep0, but it is blocked, as pflogd >> shows: 000000 rule 1/0(match): block out on ep0: 10.0.0.2.25 > > > There is no state entry and no rule that would allow traffic to be sent out > via ep0. You either have to create state on ep0 or you must allow traffic on > ep0 in both directions. I think the ruleset you are looking for is something > along the lines of: > > block drop all > > pass in on ep0 inet from 1.2.3.1 to 10.0.0.2 keep state flags S/SA > pass out on bge0 inet from 1.2.3.1 to 10.0.0.2 keep state flags S/SA > The OP didn't like that answer when I gave it to him. Maybe you've managed to provide a more felicitous wording. ;-) --Jon Radel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3283 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20080903/fdfa2fa5/smime.bin From jon at radel.com Wed Sep 3 18:49:40 2008 From: jon at radel.com (Jon Radel) Date: Wed Sep 3 18:49:46 2008 Subject: keeping state on outgoing connections fails (?) In-Reply-To: <20080903161759.GA2761@kaliope.home> References: <20080903110943.GA25396@gvr.gvr.org> <20080903152632.GA89687@icarus.home.lan> <20080903161759.GA2761@kaliope.home> Message-ID: <48BEDC35.3050802@radel.com> Peter Wullinger wrote: > I'll reply to Jeremy, since his answer somehow confused me. > > In epistula a Jeremy Chadwick, die horaque Wed Sep 3 17:26:32 2008: >> On Wed, Sep 03, 2008 at 01:09:43PM +0200, Guido van Rooij wrote: >>> Setup: FreeBSD 6.3 system with 2 interfaces: ep0 and bge0. >>> >>> ep0: 1.2.3.4/24 >>> bge0: 10.0.0.1/24 >>> >>> ruleset (made as simple as possible): >>> pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 >>> block drop out log quick on ep0 all >>> pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state > > At little bit of guessing led me to the (possible, I have not tested > this) culprit: Is your state-policy set to "floating" or "if-bound"? > > From a casual look at the log entries and traffic snapshots you have sent, > this seems to be pf working in "if-bound" mode. In this case, the > created state table entry matches incoming on bge0, but not on > outgoing on ep0 any more (packets pass through pf twice, as expected). > > This still maybe a bug, but it's common to rule out all possible > culprits before spreading blame. > My understanding is that "if-bound" would have an effect on this scenario if the OP, for example, had two interfaces on the same "side" of the firewall, say bge0 and bge1, and packets for a connection that was originally established by a packet outbound on bge0 might cross on either bge0 or bge1 traveling in the same direction with respect to the FreeBSD router with the configuration. In this case we're talking about packets that are traveling in one direction with respect to the router on bge0 and the other direction on ep0, so you'd need separate state entries no matter what you've done with if-bound. --Jon Radel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3283 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20080903/fb3fe626/smime.bin From jeremie at le-hen.org Wed Sep 3 19:30:25 2008 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Wed Sep 3 19:30:38 2008 Subject: NAT-PT (was: Crazy Question - IPv6 to IPv4 and vice versa) In-Reply-To: <20080903082619.U4624@mignon.ki.iif.hu> References: <17838240D9A5544AAA5FF95F8D520316049038B6@ad-exh01.adhost.lan> <20080903082619.U4624@mignon.ki.iif.hu> Message-ID: <20080903185757.GE72107@obiwan.tataz.chchile.org> Hi, On Wed, Sep 03, 2008 at 08:30:39AM +0200, Mohacsi Janos wrote: > 1. NAT-PT - however depracated - and not maintained the *BSD version > anymore: http://mucc.mahidol.ac.th/~ccvvs/natpt-setup.html> By the way, I've always wondered what it had been deprecated. It was quite hackish but could be very useful. It used to be implemented in KAME snapshot but has never made its path to one of the BSD. I'm sure there are good reasons for this and I'd be happy if someone could point them. Thank you. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From koitsu at FreeBSD.org Thu Sep 4 06:10:56 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Sep 4 06:11:03 2008 Subject: keeping state on outgoing connections fails (?) In-Reply-To: <20080903161759.GA2761@kaliope.home> References: <20080903110943.GA25396@gvr.gvr.org> <20080903152632.GA89687@icarus.home.lan> <20080903161759.GA2761@kaliope.home> Message-ID: <20080904061054.GA4131@icarus.home.lan> On Wed, Sep 03, 2008 at 06:17:59PM +0200, Peter Wullinger wrote: > I'll reply to Jeremy, since his answer somehow confused me. > > In epistula a Jeremy Chadwick, die horaque Wed Sep 3 17:26:32 2008: > > I'm a bit confused by these rules and your network configuration. > > Rule #1 allows any packet with a source address of 1.2.3.1, arriving on > > the ep0 interface, destined to 10.0.0.2. How exactly are packets > > arriving on ep0 (which is bound to 1.2.3.0/24) with a destination of > > 10.0.0.2 in the first place? That seems strange. Is your gateway on > > your network blindly forwarding packets between networks or something? > > Or is this FreeBSD box acting *as* a gateway? > > It seems to be a gateway, forwarding packets. What exactly do you find > strange? Have I missed something? Sorry for confusing you -- if it's a gateway, the OP needed to state such. I can't assume it's a gateway, because in this day and age people try to do crazy things with networks, especially with bridging. If it's a gateway, there's nothing strange about it. If it isn't a gateway, I can't see how any of the above would work. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From schaman at sch.bme.hu Thu Sep 4 18:30:23 2008 From: schaman at sch.bme.hu (=?iso-8859-2?Q?=22Kiss_Zolt=E1n=22?=) Date: Thu Sep 4 18:30:30 2008 Subject: pf fails to create state entries to OpenVPN-initiated sessions Message-ID: <770fd2282951.48c03735@sch.bme.hu> Hi, My company has a strange problem with OpenVPN under FreeBSD 7.0. The configuration is the following: Our central NAT firewall/VPN endpoint has two physical interfaces, one for the public Internet (called ext), and one for our intranet (int, 192.168.1.0/24). On ext there are IPSec tunnels to remote offices through gif interfaces, and int is bridged to tap0, which is used by OpenVPN. Users can seamlessly login, and access the central subnet, but there are strange effects when someone wants to access branch office networks. Note, that pf has ?set skip? options on all gif interface, on the bridge0 if and on tap0, to avoid on this side. So as I mentioned, OpenVPN users can access the 192.168.1.0/24 network, but when they send a packet to a remote subnet (e.g. 192.168.2.0/24), sometimes the firewall isn?t create a state entry, and so TCP sessions cannot be established. See this example: 2008-09-03 19:03:35.919390 rule 41/0(match): pass out on int: 192.168.1.100.55754 > 192.168.1.1.53: 61937+[|domain] 2008-09-03 19:03:36.147102 rule 0/0(match): block out on int: 192.168.2.1.3389 > 192.168.1.100.38289: S 1952258627:1952258627(0) ack 479606554 win 16384 2008-09-03 19:03:38.682145 rule 0/0(match): block out on int: 192.168.2.1.3389 > 192.168.1.100.38289: S 1952258627:1952258627(0) ack 479606554 win 16384 .1.100 is an OpenVPN client, as you see it passes pf to central subnet. But on next two row, where .2.1 is a terminal server, you can see only answer packets to TCP session initiation, which are blocked in the lack of state entry. But what?s more strange, when I want to start an RDP session again to the same server 2 minutes later, it works properly! : 2008-09-03 19:05:28.237872 rule 7/0(match): pass in on int: 192.168.1.100.38293 > 192.168.2.1.3389: S 2231405925:2231405925(0) win 5840 And I didn?t make any change on the firewall in this 2 minute! And this happens quite randomly, so I?m quite confused why it happens. The related firewall rules: @7 pass in log on int inet from 192.168.1.0/24 to any flags S/SA keep state @41 pass out log on inet inet from 192.168.1.0/24 to any flags S/SA keep state @42 pass in log on int inet from any to 192.168.16.0/24 flags S/SA keep state I tried to let it as permissive as possible. There isn?t any dynamic routing on this intranet, and inside the physical networks of our offices anybody can access anybody without any problem. My expectation, that if a packet comes from VPN client, it goes through tap0, bridge0, where it?s not filtered, pass in on int, and create a state entry, but somehow it doesn?t happens always. Do you have any idea how can I investigate this problem? Any suggestions are welcomed. Regards, Zolt?n, Kiss From remko at FreeBSD.org Fri Sep 5 22:35:25 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Fri Sep 5 22:35:36 2008 Subject: kern/127121: pf incorrect log priority Message-ID: <200809052235.m85MZPPa028477@freefall.freebsd.org> Synopsis: pf incorrect log priority Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: remko Responsible-Changed-When: Fri Sep 5 22:35:05 UTC 2008 Responsible-Changed-Why: reassign to pf team http://www.freebsd.org/cgi/query-pr.cgi?pr=127121 From secucatcher at free.fr Sat Sep 6 13:35:41 2008 From: secucatcher at free.fr (secucatcher@free.fr) Date: Sat Sep 6 13:35:48 2008 Subject: (no subject) Message-ID: <1220706618.48c2813ab9cc6@imp.free.fr> hi everybody, my work now is to change a linux firewall with iptables to freebsd/pf/carp i migrate 6500 lines of iptables with no problem in ten day there is 400 servers to filter and maybe more in the new datacenter (1400/1700) the firewall do nat ! they have something like this: iptables -t nat -I PREROUTING -d -j DNAT --to the idea behind is that two server on the same lan behind the firewall could be seen each other like they are on internet in different place, they use webservices and they already deal with that. the first contact the second not on the lan but through the firewall with public address. the firewall must be in production next week, they just told me this new thing they want this morning (and it was not in the first part i migrate) and i finish the last three hours i must do on this project. if i didn't win ;) they stay with iptables. i try some idea http://www.openbsd.org/faq/pf/rdr.html but most of what i do for the server is binat and not rdr. i can't deal with netcat for such a project , pftpx is already a bit dirty for them instead of conntrack thank you for your help From secucatcher at free.fr Sat Sep 6 18:40:45 2008 From: secucatcher at free.fr (secucatcher@free.fr) Date: Sat Sep 6 18:40:51 2008 Subject: (no subject) In-Reply-To: <1220706618.48c2813ab9cc6@imp.free.fr> References: <1220706618.48c2813ab9cc6@imp.free.fr> Message-ID: <20080906204042.16491860@desktop> sorry for the disturbing time i find: rdr on $if_ext proto tcp from $int_net to port 80 -> \ nat on $if_int inet from to any -> i nat on the internal interface and it is just working From fox at verio.net Sat Sep 6 19:14:13 2008 From: fox at verio.net (David DeSimone) Date: Sat Sep 6 19:14:19 2008 Subject: bidirectional NAT in PF? In-Reply-To: <20080906204042.16491860@desktop> References: <1220706618.48c2813ab9cc6@imp.free.fr> <20080906204042.16491860@desktop> Message-ID: <20080906191403.GJ1949@verio.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 secucatcher@free.fr wrote: > > sorry for the disturbing time > i find: > rdr on $if_ext proto tcp from $int_net to port 80 -> \ > > > nat on $if_int inet from to any -> > > i nat on the internal interface and it is just working Is this true, that PF supports bidirectional NAT? That is, NAT of both the source and the destination IP in a connection, at the same time? I had attempted this in the past but I could not find a rule syntax that would accomplish it. Looking at the above, it appears that this may be possible because PF processes the rulebase twice for forwarded traffic; once on input, and again on output. If the inbound packet matched a "rdr" rule, and the outbound matched a "nat" rule, this would accomplish bidirectional NAT? Interesting technique, if it works. - -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFIwtZ7FSrKRjX5eCoRAgMIAJ9x6RUt1XwvKs67moiSKa+e1FMt2wCfYPJ2 GdSU08YZvJWvjFOw3zd8kpI= =92NZ -----END PGP SIGNATURE----- This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From secucatcher at free.fr Sat Sep 6 19:41:58 2008 From: secucatcher at free.fr (secucatcher@free.fr) Date: Sat Sep 6 19:42:04 2008 Subject: bidirectional NAT in PF? In-Reply-To: <20080906191403.GJ1949@verio.net> References: <1220706618.48c2813ab9cc6@imp.free.fr> <20080906204042.16491860@desktop> <20080906191403.GJ1949@verio.net> Message-ID: <20080906214155.52c6f2e7@desktop> > Is this true, that PF supports bidirectional NAT? That is, NAT of > both the source and the destination IP in a connection, at the same > time? > > I had attempted this in the past but I could not find a rule syntax > that would accomplish it. Looking at the above, it appears that this > may be possible because PF processes the rulebase twice for forwarded > traffic; once on input, and again on output. If the inbound packet > matched a "rdr" rule, and the outbound matched a "nat" rule, this > would accomplish bidirectional NAT? > > Interesting technique, if it works. "binat" was not working for u ? binat on $ifext from private-ip to any -> public-ip From secucatcher at free.fr Sat Sep 6 19:56:09 2008 From: secucatcher at free.fr (secucatcher@free.fr) Date: Sat Sep 6 19:56:22 2008 Subject: bidirectional NAT in PF? In-Reply-To: <20080906191403.GJ1949@verio.net> References: <1220706618.48c2813ab9cc6@imp.free.fr> <20080906204042.16491860@desktop> <20080906191403.GJ1949@verio.net> Message-ID: <20080906215607.60b235f9@desktop> Le Sat, 6 Sep 2008 14:14:04 -0500 "David DeSimone" a pris sa plume: > rdr on $if_ext proto tcp from $int_net to port 80 -> \ > > > > > > nat on $if_int inet from to any -> > > > > i nat on the internal interface and it is just working to be more clear the priv ip and pub ip on the tww line are different and are own by the two server than must connect like they are on the net From fox at verio.net Sat Sep 6 22:31:15 2008 From: fox at verio.net (David DeSimone) Date: Sat Sep 6 22:31:21 2008 Subject: bidirectional NAT in PF? In-Reply-To: <20080906214155.52c6f2e7@desktop> References: <1220706618.48c2813ab9cc6@imp.free.fr> <20080906204042.16491860@desktop> <20080906191403.GJ1949@verio.net> <20080906214155.52c6f2e7@desktop> Message-ID: <20080906223103.GK1949@verio.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 secucatcher@free.fr wrote: > > > Is this true, that PF supports bidirectional NAT? That is, NAT of > > both the source and the destination IP in a connection, at the same > > time? > > "binat" was not working for u ? > binat on $ifext from private-ip to any -> public-ip I think I am using the wrong terminology. I should probably call it "double NAT" to differentiate it. "binat" works fine but it still only changes ONE of the IP's being translated (the source IP). In PF, you can use "nat" to translate the source IP, and "redir" to change the dest IP, but what if you want to change both? There is no direct way to do this, so I am wondering if two different rules could be matched at different times during the packet's transit through the gateway. - -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFIwwSnFSrKRjX5eCoRAsVtAJ97T8ALAm7SnrAx362biLvFNK+4zwCfRblb l1wrXShJas2NfmKJYXpz/iE= =RNSP -----END PGP SIGNATURE----- This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From secucatcher at free.fr Sun Sep 7 07:14:54 2008 From: secucatcher at free.fr (secucatcher@free.fr) Date: Sun Sep 7 07:15:02 2008 Subject: bidirectional NAT in PF? In-Reply-To: <20080906223103.GK1949@verio.net> References: <1220706618.48c2813ab9cc6@imp.free.fr> <20080906204042.16491860@desktop> <20080906191403.GJ1949@verio.net> <20080906214155.52c6f2e7@desktop> <20080906223103.GK1949@verio.net> Message-ID: <20080907091452.65d14b4a@desktop> Le Sat, 6 Sep 2008 17:31:04 -0500 "David DeSimone" a pris sa plume: > There is no direct way to do > this, so I am wondering if two different rules could be matched at > different times during the packet's transit through the gateway. yes maybe nat and a rdr could be the solution. From yar at comp.chem.msu.su Sun Sep 7 13:58:18 2008 From: yar at comp.chem.msu.su (Yar Tikhiy) Date: Sun Sep 7 13:58:24 2008 Subject: pf creating states by default now? Message-ID: Hi all, After upgrading a production machine from 6.x to 7.x, I noticed that pf would create states from rules without "keep state". IMSMR, it hadn't happened before, and the pf.conf(5) manpage still says one has to specify "keep state" explicitly for pf to create states. Just examined this issue more closely on a CURRENT machine. If I load the following simple pf.conf file: > set skip on lo0 > block return all > pass out all > pass in inet proto icmp all icmp-type echoreq > pass in inet proto tcp from any to any port 22 then I get these actual rules as shown by "pfctl -s rules": > block return all > pass out all flags S/SA keep state > pass in inet proto icmp all icmp-type echoreq keep state > pass in inet proto tcp from any to any port = ssh flags S/SA keep > state Looks like pfctl or pf itself added stateful semantics to my pf.conf that weren't there initially. Is this effect intended and, if so, how can I tell pf not to create states from certain rules? Thanks! And excuse me if I'm just missing something. Yar From remko at FreeBSD.org Sun Sep 7 15:30:02 2008 From: remko at FreeBSD.org (Remko Lodder) Date: Sun Sep 7 15:30:09 2008 Subject: pf creating states by default now? In-Reply-To: References: Message-ID: <48C3ED10.7080601@FreeBSD.org> Yar Tikhiy wrote: > > > Looks like pfctl or pf itself added stateful semantics to my pf.conf > that weren't there initially. Is this effect intended and, if so, how > can I tell pf not to create states from certain rules? > > Thanks! And excuse me if I'm just missing something. > > Yar > Hi Yar, Yes since 7.0 this behaviour is intented. flags S/SA and keep state are implied now. If you do not want to use them you set ''no state'' to get rid of the statefull filter. I think that also grabs the flags S/SA because that tells you when the statefull filter is being setup. Hope this helps, remko -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From ohauer at gmx.de Sun Sep 7 15:58:35 2008 From: ohauer at gmx.de (Olli Hauer) Date: Sun Sep 7 15:58:42 2008 Subject: pf creating states by default now? In-Reply-To: References: Message-ID: <20080907153151.310630@gmx.net> > Hi all, > > After upgrading a production machine from 6.x to 7.x, > I noticed that pf would create states from rules without > "keep state". IMSMR, it hadn't happened before, and > the pf.conf(5) manpage still says one has to specify > "keep state" explicitly for pf to create states. > > Just examined this issue more closely on a CURRENT machine. > If I load the following simple pf.conf file: > > > set skip on lo0 > > block return all > > pass out all > > pass in inet proto icmp all icmp-type echoreq > > pass in inet proto tcp from any to any port 22 > > > then I get these actual rules as shown by "pfctl -s rules": > > > block return all > > pass out all flags S/SA keep state > > pass in inet proto icmp all icmp-type echoreq keep state > > pass in inet proto tcp from any to any port = ssh flags S/SA keep > > state > > > Looks like pfctl or pf itself added stateful semantics to my pf.conf > that weren't there initially. Is this effect intended and, if so, how > can I tell pf not to create states from certain rules? > > Thanks! And excuse me if I'm just missing something. > > Yar > Yes, it is not in man pf.conf(5) but in the Rel Notes http://www.freebsd.org/releases/7.0R/relnotes.html See also http://openbsd.org/faq/upgrade41.html (1.2. Operational changes) The man page match the OpenBSD one http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf&sektion=5&manpath=OpenBSD+4.3 What is your reason for not using 'S/SA keep state' at this rules? You can disable this with the 'no state' keyword Regards, olli -- Psssst! Schon das coole Video vom GMX MultiMessenger gesehen? Der Eine f?r Alle: http://www.gmx.net/de/go/messenger03 From yar at comp.chem.msu.su Sun Sep 7 20:53:38 2008 From: yar at comp.chem.msu.su (Yar Tikhiy) Date: Sun Sep 7 20:53:48 2008 Subject: pf creating states by default now? In-Reply-To: <20080907153151.310630@gmx.net> References: <20080907153151.310630@gmx.net> Message-ID: On Sep 7, 2008, at 7:31 PM, Olli Hauer wrote: >> Looks like pfctl or pf itself added stateful semantics to my pf.conf >> that weren't there initially. Is this effect intended and, if so, >> how >> can I tell pf not to create states from certain rules? >> >> Thanks! And excuse me if I'm just missing something. >> >> Yar >> > > Yes, it is not in man pf.conf(5) but in the Rel Notes http:// > www.freebsd.org/releases/7.0R/relnotes.html > See also http://openbsd.org/faq/upgrade41.html (1.2. Operational > changes) Thank you for pointing me out! > The man page match the OpenBSD one http://www.openbsd.org/cgi-bin/ > man.cgi?query=pf.conf&sektion=5&manpath=OpenBSD+4.3 And in OpenBSD-current the manpage still reads: "...keep state must be specified explicitly to apply [stateful tracking] options to a rule." Perhaps we can fix this issue in our src tree and then send the patch upstream to the OpenBSD folks, can't we? In Subversion, the price of touching an imported file is not nearly as high as it used to be in CVS. > What is your reason for not using 'S/SA keep state' at this rules? I think I'm hitting some obscure issue with pf state synchronisation between two routers, so I'd like to prevent at least internal connections from being torn when a switch from the master to the backup router occurs via carp. The routers have a lot of vlan interfaces, and I'd like to limit stateful filtering to the uplink vlan only. > You can disable this with the 'no state' keyword I see now. Your help is much appreciated! Yar From pf_free at chrissmith.org Sun Sep 7 21:09:11 2008 From: pf_free at chrissmith.org (Chris Smith) Date: Sun Sep 7 21:09:17 2008 Subject: pf creating states by default now? In-Reply-To: References: <20080907153151.310630@gmx.net> Message-ID: <200809071709.06945.pf_free@chrissmith.org> On Sunday 07 September 2008 04:53:20 pm Yar Tikhiy wrote: > And in OpenBSD-current the manpage still reads: "...keep state > must be specified explicitly to apply [stateful tracking] options > to a rule." Not in the -current running here. The manpage reads: "A number of options related to stateful tracking can be applied on a per-rule basis. keep state, modulate state and synproxy state support these options, and keep state must be specified explicitly to apply options to a rule." And the "options" referred to are listed in that section, such as max, timeout, no-sync, sloppy, etc. If you're not applying the options, keep state is implied. From yar at comp.chem.msu.su Sun Sep 7 21:24:17 2008 From: yar at comp.chem.msu.su (Yar Tikhiy) Date: Sun Sep 7 21:24:26 2008 Subject: pf creating states by default now? In-Reply-To: <200809071709.06945.pf_free@chrissmith.org> References: <20080907153151.310630@gmx.net> <200809071709.06945.pf_free@chrissmith.org> Message-ID: <0663003B-EF24-4A3C-BB2F-53C2ED99DC16@comp.chem.msu.su> On Sep 8, 2008, at 1:09 AM, Chris Smith wrote: > On Sunday 07 September 2008 04:53:20 pm Yar Tikhiy wrote: >> And in OpenBSD-current the manpage still reads: "...keep state >> must be specified explicitly to apply [stateful tracking] options >> to a rule." > > Not in the -current running here. The manpage reads: > "A number of options related to stateful tracking can be applied on > a per-rule > basis. keep state, modulate state and synproxy state support these > options, > and keep state must be specified explicitly to apply options to a > rule." > > And the "options" referred to are listed in that section, such as max, > timeout, no-sync, sloppy, etc. If you're not applying the options, > keep state > is implied. Sorry, I misread that paragraph. I also missed this: pass The packet is passed; state is created state unless the no state option is specified. By default pf(4) filters packets statefully; the first time a packet matches a pass rule, a state entry is created; for subsequent packets the filter checks whether the packet matches any state. Excuse me for the noise. Yar From ohauer at gmx.de Sun Sep 7 21:31:45 2008 From: ohauer at gmx.de (Olli Hauer) Date: Sun Sep 7 21:31:53 2008 Subject: pf creating states by default now? In-Reply-To: References: <20080907153151.310630@gmx.net> Message-ID: <20080907213143.15910@gmx.net> > >> Looks like pfctl or pf itself added stateful semantics to my pf.conf > >> that weren't there initially. Is this effect intended and, if so, > >> how > >> can I tell pf not to create states from certain rules? > >> > >> Thanks! And excuse me if I'm just missing something. > >> > >> Yar > >> > > > > Yes, it is not in man pf.conf(5) but in the Rel Notes http:// > > www.freebsd.org/releases/7.0R/relnotes.html > > See also http://openbsd.org/faq/upgrade41.html (1.2. Operational > > changes) > > Thank you for pointing me out! > > > The man page match the OpenBSD one http://www.openbsd.org/cgi-bin/ > > man.cgi?query=pf.conf&sektion=5&manpath=OpenBSD+4.3 > > And in OpenBSD-current the manpage still reads: "...keep state > must be specified explicitly to apply [stateful tracking] options > to a rule." > > Perhaps we can fix this issue in our src tree and then send the > patch upstream to the OpenBSD folks, can't we? In Subversion, the > price of touching an imported file is not nearly as high as it used > to be in CVS. > Yes, parts of the document shoud be updated. > > What is your reason for not using 'S/SA keep state' at this rules? > > I think I'm hitting some obscure issue with pf state synchronisation > between two routers, so I'd like to prevent at least internal > connections > from being torn when a switch from the master to the backup router > occurs > via carp. The routers have a lot of vlan interfaces, and I'd like to > limit > stateful filtering to the uplink vlan only. > > > You can disable this with the 'no state' keyword > > I see now. Your help is much appreciated! > > Yar Hm, maybe something like this can be your solution (example for ssh traffic) # no state rule to manage the router interface (not carp/vlans/cloned interfaces) pass in quick inet proto tcp from $internal to $if_base:0 port 22 no state # all other ssh traffic pass in inet proto tcp from any to any port 22 Regards, olli -- Psssst! Schon das coole Video vom GMX MultiMessenger gesehen? Der Eine f?r Alle: http://www.gmx.net/de/go/messenger03 From bugmaster at FreeBSD.org Mon Sep 8 02:22:25 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 8 02:23:48 2008 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200809080222.m882MOks006762@freefall.freebsd.org> 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/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/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 kern/82271 pf [pf] cbq scheduler cause bad latency 19 problems total. Bugs can be in one of several states: o - open A problem report has been submitted, no sanity checking performed. a - analyzed The problem is understood and a solution is being sought. f - feedback Further work requires additional information from the originator or the community - possibly confirmation of the effectiveness of a proposed solution. p - patched A patch has been committed, but some issues (MFC and / or confirmation from originator) are still open. r - repocopy The resolution of the problem report is dependent on a repocopy operation within the CVS repository which is awaiting completion. s - suspended The problem is not being worked on, due to lack of information or resources. This is a prime candidate for somebody who is looking for a project to do. If the problem cannot be solved at all, it will be closed, rather than suspended. c - closed A problem report is closed when any changes have been integrated, documented, and tested -- or when fixing the problem is abandoned. From mouss at netoyen.net Mon Sep 8 07:05:07 2008 From: mouss at netoyen.net (mouss) Date: Mon Sep 8 07:05:17 2008 Subject: bidirectional NAT in PF? In-Reply-To: <20080906223103.GK1949@verio.net> References: <1220706618.48c2813ab9cc6@imp.free.fr> <20080906204042.16491860@desktop> <20080906191403.GJ1949@verio.net> <20080906214155.52c6f2e7@desktop> <20080906223103.GK1949@verio.net> Message-ID: <48C4CB18.6010905@netoyen.net> David DeSimone wrote: > I think I am using the wrong terminology. I should probably call it > "double NAT" to differentiate it. "binat" works fine but it still only > changes ONE of the IP's being translated (the source IP). In PF, you > can use "nat" to translate the source IP, and "redir" to change the dest > IP, but what if you want to change both? There is no direct way to do > this, so I am wondering if two different rules could be matched at > different times during the packet's transit through the gateway. > the common way is to use two rules: a nat and an rdr. This is used to fix the "reflection problem" for instance. I have used it with ipfilter in the past (though not for a reflection issue, but for a dmz setup), but I guess it works similarly on pf and other filters. From kirgudu at kirgudu.org Mon Sep 8 15:36:10 2008 From: kirgudu at kirgudu.org (Dmitry Rybin) Date: Mon Sep 8 15:36:18 2008 Subject: FreeBSD 7.1-PRERELEASE Trouble Message-ID: <9bc4ff5c0809080813t1c370b72pce80dfa64f91fa41@mail.gmail.com> PF doesn't block some IP!!!! === pf.conf === ext_if="bge0" table { 78.107.71.38 89.179.195.34 } block quick from pass out pass in === pf.conf === # pfctl -e -f /etc/pf.conf # tcpdump -netxi bge0 host 89.179.195.34 00:1a:a1:69:35:43 > 00:1c:c4:81:2f:9e, ethertype IPv4 (0x0800), length 69: 89.179.195.34.2357 > 195.14.50.21.53: 35869+ A? emils.com. (27) 0x0000: 4500 0037 3034 0000 3811 4089 59b3 c322 0x0010: c30e 3215 0935 0035 0023 0314 8c1d 0100 0x0020: 0001 0000 0000 0000 0565 6d69 6c73 0363 0x0030: 6f6d 0000 0100 01 00:1c:c4:81:2f:9e > 00:00:0c:07:ac:00, ethertype IPv4 (0x0800), length 84: 195.14.50.21.53 > 89.179.195.34.2357: 48025 ServFail 0/0/1 (42) 0x0000: 4500 0046 84a8 0000 4011 0000 c30e 3215 0x0010: 59b3 c322 0035 0935 0032 c7de bb99 8182 0x0020: 0001 0000 0000 0001 0377 7777 0565 6d69 0x0030: 6c73 0363 6f6d 0000 0100 0100 0029 1000 0x0040: 0000 0000 0000 00:1c:c4:81:2f:9e > 00:00:0c:07:ac:00, ethertype IPv4 (0x0800), length 73: 195.14.50.21.53 > 89.179.195.34.2357: 22012 ServFail 0/0/0 (31) 0x0000: 4500 003b 84a9 0000 4011 0000 c30e 3215 0x0010: 59b3 c322 0035 0935 0027 3dbc 55fc 8182 0x0020: 0001 0000 0000 0000 0377 7777 0565 6d69 0x0030: 6c73 0363 6f6d 0000 0100 01 00:1c:c4:81:2f:9e > 00:00:0c:07:ac:00, ethertype IPv4 (0x0800), length 69: 195.14.50.21.53 > 89.179.195.34.2357: 35869 ServFail 0/0/0 (27) 0x0000: 4500 0037 84ac 0000 4011 0000 c30e 3215 0x0010: 59b3 c322 0035 0935 0023 8291 8c1d 8182 0x0020: 0001 0000 0000 0000 0565 6d69 6c73 0363 0x0030: 6f6d 0000 0100 01 00:1a:a1:69:35:43 > 00:1c:c4:81:2f:9e, ethertype IPv4 (0x0800), length 73: 89.179.195.34.2357 > 195.14.50.21.53: 48025+ A? www.emils.com. (31) 0x0000: 4500 003b 3035 0000 3811 4084 59b3 c322 0x0010: c30e 3215 0935 0035 0027 58a1 bb99 0100 0x0020: 0001 0000 0000 0000 0377 7777 0565 6d69 0x0030: 6c73 0363 6f6d 0000 0100 01 00:1c:c4:81:2f:9e > 00:00:0c:07:ac:00, ethertype IPv4 (0x0800), length 73: 195.14.50.21.53 > 89.179.195.34.2357: 48025 ServFail 0/0/0 (31) 0x0000: 4500 003b 84ae 0000 4011 0000 c30e 3215 0x0010: 59b3 c322 0035 0935 0027 d81e bb99 8182 0x0020: 0001 0000 0000 0000 0377 7777 0565 6d69 0x0030: 6c73 0363 6f6d 0000 0100 01 tcpdump -netxi bge0 host 78.107.71.38 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bge0, link-type EN10MB (Ethernet), capture size 96 bytes 00:1a:a1:69:35:43 > 00:1c:c4:81:2f:9e, ethertype IPv4 (0x0800), length 94: 78.107.71.38.37367 > 195.14.50.21.53: 38168+ A? nc-71-51-232-31.dhcp.embarqhsd.net. (52) 0x0000: 4500 0050 ae4f 4000 3b11 0699 4e6b 4726 0x0010: c30e 3215 91f7 0035 003c e6ca 9518 0100 0x0020: 0001 0000 0000 0000 0f6e 632d 3731 2d35 0x0030: 312d 3233 322d 3331 0464 6863 7009 656d 0x0040: 6261 7271 6873 6403 6e65 7400 0001 0001 00:1a:a1:69:35:43 > 00:1c:c4:81:2f:9e, ethertype IPv4 (0x0800), length 89: 78.107.71.38.37368 > 195.14.50.21.53: 50276+ A? 166.156.122.89.bl.spamcop.net. (47) 0x0000: 4500 004b ae68 4000 3b11 0685 4e6b 4726 0x0010: c30e 3215 91f8 0035 0037 18d5 c464 0100 0x0020: 0001 0000 0000 0000 0331 3636 0331 3536 0x0030: 0331 3232 0238 3902 626c 0773 7061 6d63 0x0040: 6f70 036e 6574 0000 0100 01 Add to pf.conf block quick from 89.179.195.34 - same, doesn't work. May be trouble in config? From koitsu at FreeBSD.org Mon Sep 8 15:51:42 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 8 15:51:51 2008 Subject: FreeBSD 7.1-PRERELEASE Trouble In-Reply-To: <9bc4ff5c0809080813t1c370b72pce80dfa64f91fa41@mail.gmail.com> References: <9bc4ff5c0809080813t1c370b72pce80dfa64f91fa41@mail.gmail.com> Message-ID: <20080908155139.GA72633@icarus.home.lan> On Mon, Sep 08, 2008 at 07:13:35PM +0400, Dmitry Rybin wrote: > PF doesn't block some IP!!!! > > === pf.conf === > > ext_if="bge0" > table { 78.107.71.38 89.179.195.34 } > > block quick from > pass out > pass in > === pf.conf === > > # pfctl -e -f /etc/pf.conf > > # tcpdump -netxi bge0 host 89.179.195.34 > 00:1a:a1:69:35:43 > 00:1c:c4:81:2f:9e, ethertype IPv4 (0x0800), length 69: > 89.179.195.34.2357 > 195.14.50.21.53: 35869+ A? emils.com. (27) > 0x0000: 4500 0037 3034 0000 3811 4089 59b3 c322 > 0x0010: c30e 3215 0935 0035 0023 0314 8c1d 0100 > 0x0020: 0001 0000 0000 0000 0565 6d69 6c73 0363 > 0x0030: 6f6d 0000 0100 01 > 00:1c:c4:81:2f:9e > 00:00:0c:07:ac:00, ethertype IPv4 (0x0800), length 84: > 195.14.50.21.53 > 89.179.195.34.2357: 48025 ServFail 0/0/1 (42) > 0x0000: 4500 0046 84a8 0000 4011 0000 c30e 3215 > 0x0010: 59b3 c322 0035 0935 0032 c7de bb99 8182 > 0x0020: 0001 0000 0000 0001 0377 7777 0565 6d69 > 0x0030: 6c73 0363 6f6d 0000 0100 0100 0029 1000 > 0x0040: 0000 0000 0000 > 00:1c:c4:81:2f:9e > 00:00:0c:07:ac:00, ethertype IPv4 (0x0800), length 73: > 195.14.50.21.53 > 89.179.195.34.2357: 22012 ServFail 0/0/0 (31) > 0x0000: 4500 003b 84a9 0000 4011 0000 c30e 3215 > 0x0010: 59b3 c322 0035 0935 0027 3dbc 55fc 8182 > 0x0020: 0001 0000 0000 0000 0377 7777 0565 6d69 > 0x0030: 6c73 0363 6f6d 0000 0100 01 > 00:1c:c4:81:2f:9e > 00:00:0c:07:ac:00, ethertype IPv4 (0x0800), length 69: > 195.14.50.21.53 > 89.179.195.34.2357: 35869 ServFail 0/0/0 (27) > 0x0000: 4500 0037 84ac 0000 4011 0000 c30e 3215 > 0x0010: 59b3 c322 0035 0935 0023 8291 8c1d 8182 > 0x0020: 0001 0000 0000 0000 0565 6d69 6c73 0363 > 0x0030: 6f6d 0000 0100 01 > 00:1a:a1:69:35:43 > 00:1c:c4:81:2f:9e, ethertype IPv4 (0x0800), length 73: > 89.179.195.34.2357 > 195.14.50.21.53: 48025+ A? www.emils.com. (31) > 0x0000: 4500 003b 3035 0000 3811 4084 59b3 c322 > 0x0010: c30e 3215 0935 0035 0027 58a1 bb99 0100 > 0x0020: 0001 0000 0000 0000 0377 7777 0565 6d69 > 0x0030: 6c73 0363 6f6d 0000 0100 01 > 00:1c:c4:81:2f:9e > 00:00:0c:07:ac:00, ethertype IPv4 (0x0800), length 73: > 195.14.50.21.53 > 89.179.195.34.2357: 48025 ServFail 0/0/0 (31) > 0x0000: 4500 003b 84ae 0000 4011 0000 c30e 3215 > 0x0010: 59b3 c322 0035 0935 0027 d81e bb99 8182 > 0x0020: 0001 0000 0000 0000 0377 7777 0565 6d69 > 0x0030: 6c73 0363 6f6d 0000 0100 01 > > tcpdump -netxi bge0 host 78.107.71.38 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on bge0, link-type EN10MB (Ethernet), capture size 96 bytes > 00:1a:a1:69:35:43 > 00:1c:c4:81:2f:9e, ethertype IPv4 (0x0800), length 94: > 78.107.71.38.37367 > 195.14.50.21.53: 38168+ A? > nc-71-51-232-31.dhcp.embarqhsd.net. (52) > 0x0000: 4500 0050 ae4f 4000 3b11 0699 4e6b 4726 > 0x0010: c30e 3215 91f7 0035 003c e6ca 9518 0100 > 0x0020: 0001 0000 0000 0000 0f6e 632d 3731 2d35 > 0x0030: 312d 3233 322d 3331 0464 6863 7009 656d > 0x0040: 6261 7271 6873 6403 6e65 7400 0001 0001 > 00:1a:a1:69:35:43 > 00:1c:c4:81:2f:9e, ethertype IPv4 (0x0800), length 89: > 78.107.71.38.37368 > 195.14.50.21.53: 50276+ A? > 166.156.122.89.bl.spamcop.net. (47) > 0x0000: 4500 004b ae68 4000 3b11 0685 4e6b 4726 > 0x0010: c30e 3215 91f8 0035 0037 18d5 c464 0100 > 0x0020: 0001 0000 0000 0000 0331 3636 0331 3536 > 0x0030: 0331 3232 0238 3902 626c 0773 7061 6d63 > 0x0040: 6f70 036e 6574 0000 0100 01 > > Add to pf.conf > block quick from 89.179.195.34 - same, doesn't work. > > May be trouble in config? Please show the output of "pfctl -s rules". -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Mon Sep 8 16:04:37 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 8 16:04:44 2008 Subject: FreeBSD 7.1-PRERELEASE Trouble In-Reply-To: <20080908155139.GA72633@icarus.home.lan> References: <9bc4ff5c0809080813t1c370b72pce80dfa64f91fa41@mail.gmail.com> <20080908155139.GA72633@icarus.home.lan> Message-ID: <20080908160434.GA72812@icarus.home.lan> On Mon, Sep 08, 2008 at 08:51:39AM -0700, Jeremy Chadwick wrote: > On Mon, Sep 08, 2008 at 07:13:35PM +0400, Dmitry Rybin wrote: > > PF doesn't block some IP!!!! > > > > === pf.conf === > > > > ext_if="bge0" > > table { 78.107.71.38 89.179.195.34 } > > > > block quick from > > pass out > > pass in > > === pf.conf === > > > > # pfctl -e -f /etc/pf.conf > > > > # tcpdump -netxi bge0 host 89.179.195.34 > > 00:1a:a1:69:35:43 > 00:1c:c4:81:2f:9e, ethertype IPv4 (0x0800), length 69: > > 89.179.195.34.2357 > 195.14.50.21.53: 35869+ A? emils.com. (27) > > 0x0000: 4500 0037 3034 0000 3811 4089 59b3 c322 > > 0x0010: c30e 3215 0935 0035 0023 0314 8c1d 0100 > > 0x0020: 0001 0000 0000 0000 0565 6d69 6c73 0363 > > 0x0030: 6f6d 0000 0100 01 > > 00:1c:c4:81:2f:9e > 00:00:0c:07:ac:00, ethertype IPv4 (0x0800), length 84: > > 195.14.50.21.53 > 89.179.195.34.2357: 48025 ServFail 0/0/1 (42) > > 0x0000: 4500 0046 84a8 0000 4011 0000 c30e 3215 > > 0x0010: 59b3 c322 0035 0935 0032 c7de bb99 8182 > > 0x0020: 0001 0000 0000 0001 0377 7777 0565 6d69 > > 0x0030: 6c73 0363 6f6d 0000 0100 0100 0029 1000 > > 0x0040: 0000 0000 0000 > > 00:1c:c4:81:2f:9e > 00:00:0c:07:ac:00, ethertype IPv4 (0x0800), length 73: > > 195.14.50.21.53 > 89.179.195.34.2357: 22012 ServFail 0/0/0 (31) > > 0x0000: 4500 003b 84a9 0000 4011 0000 c30e 3215 > > 0x0010: 59b3 c322 0035 0935 0027 3dbc 55fc 8182 > > 0x0020: 0001 0000 0000 0000 0377 7777 0565 6d69 > > 0x0030: 6c73 0363 6f6d 0000 0100 01 > > 00:1c:c4:81:2f:9e > 00:00:0c:07:ac:00, ethertype IPv4 (0x0800), length 69: > > 195.14.50.21.53 > 89.179.195.34.2357: 35869 ServFail 0/0/0 (27) > > 0x0000: 4500 0037 84ac 0000 4011 0000 c30e 3215 > > 0x0010: 59b3 c322 0035 0935 0023 8291 8c1d 8182 > > 0x0020: 0001 0000 0000 0000 0565 6d69 6c73 0363 > > 0x0030: 6f6d 0000 0100 01 > > 00:1a:a1:69:35:43 > 00:1c:c4:81:2f:9e, ethertype IPv4 (0x0800), length 73: > > 89.179.195.34.2357 > 195.14.50.21.53: 48025+ A? www.emils.com. (31) > > 0x0000: 4500 003b 3035 0000 3811 4084 59b3 c322 > > 0x0010: c30e 3215 0935 0035 0027 58a1 bb99 0100 > > 0x0020: 0001 0000 0000 0000 0377 7777 0565 6d69 > > 0x0030: 6c73 0363 6f6d 0000 0100 01 > > 00:1c:c4:81:2f:9e > 00:00:0c:07:ac:00, ethertype IPv4 (0x0800), length 73: > > 195.14.50.21.53 > 89.179.195.34.2357: 48025 ServFail 0/0/0 (31) > > 0x0000: 4500 003b 84ae 0000 4011 0000 c30e 3215 > > 0x0010: 59b3 c322 0035 0935 0027 d81e bb99 8182 > > 0x0020: 0001 0000 0000 0000 0377 7777 0565 6d69 > > 0x0030: 6c73 0363 6f6d 0000 0100 01 > > > > tcpdump -netxi bge0 host 78.107.71.38 > > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > > listening on bge0, link-type EN10MB (Ethernet), capture size 96 bytes > > 00:1a:a1:69:35:43 > 00:1c:c4:81:2f:9e, ethertype IPv4 (0x0800), length 94: > > 78.107.71.38.37367 > 195.14.50.21.53: 38168+ A? > > nc-71-51-232-31.dhcp.embarqhsd.net. (52) > > 0x0000: 4500 0050 ae4f 4000 3b11 0699 4e6b 4726 > > 0x0010: c30e 3215 91f7 0035 003c e6ca 9518 0100 > > 0x0020: 0001 0000 0000 0000 0f6e 632d 3731 2d35 > > 0x0030: 312d 3233 322d 3331 0464 6863 7009 656d > > 0x0040: 6261 7271 6873 6403 6e65 7400 0001 0001 > > 00:1a:a1:69:35:43 > 00:1c:c4:81:2f:9e, ethertype IPv4 (0x0800), length 89: > > 78.107.71.38.37368 > 195.14.50.21.53: 50276+ A? > > 166.156.122.89.bl.spamcop.net. (47) > > 0x0000: 4500 004b ae68 4000 3b11 0685 4e6b 4726 > > 0x0010: c30e 3215 91f8 0035 0037 18d5 c464 0100 > > 0x0020: 0001 0000 0000 0000 0331 3636 0331 3536 > > 0x0030: 0331 3232 0238 3902 626c 0773 7061 6d63 > > 0x0040: 6f70 036e 6574 0000 0100 01 > > > > Add to pf.conf > > block quick from 89.179.195.34 - same, doesn't work. > > > > May be trouble in config? > > Please show the output of "pfctl -s rules". Also, you might want to ensure the entries in the table are getting hit: pfctl -T show -t dnsflood -v If the counters for Block are getting incremented, then the rule is working. What might be happening is pf has a state table entry which is allowing the machine in table to still continue sending packets to it, on the same TCP/UDP socket as before. You can verify this by using "pfctl -s state | grep ip" To remove the states, use pfctl -k ip. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From jille at quis.cx Mon Sep 8 16:12:32 2008 From: jille at quis.cx (Jille) Date: Mon Sep 8 16:12:39 2008 Subject: FreeBSD 7.1-PRERELEASE Trouble In-Reply-To: <9bc4ff5c0809080813t1c370b72pce80dfa64f91fa41@mail.gmail.com> References: <9bc4ff5c0809080813t1c370b72pce80dfa64f91fa41@mail.gmail.com> Message-ID: <48C548A8.9030204@quis.cx> Hello, Dmitry Rybin wrote: > PF doesn't block some IP!!!! > > === pf.conf === > > ext_if="bge0" > table { 78.107.71.38 89.179.195.34 } Afaik you need to separate them with a comma (,) -- Jille > > block quick from > pass out > pass in > === pf.conf === > > # pfctl -e -f /etc/pf.conf > > # tcpdump -netxi bge0 host 89.179.195.34 > 00:1a:a1:69:35:43 > 00:1c:c4:81:2f:9e, ethertype IPv4 (0x0800), length 69: > 89.179.195.34.2357 > 195.14.50.21.53: 35869+ A? emils.com. (27) > 0x0000: 4500 0037 3034 0000 3811 4089 59b3 c322 > 0x0010: c30e 3215 0935 0035 0023 0314 8c1d 0100 > 0x0020: 0001 0000 0000 0000 0565 6d69 6c73 0363 > 0x0030: 6f6d 0000 0100 01 > 00:1c:c4:81:2f:9e > 00:00:0c:07:ac:00, ethertype IPv4 (0x0800), length 84: > 195.14.50.21.53 > 89.179.195.34.2357: 48025 ServFail 0/0/1 (42) > 0x0000: 4500 0046 84a8 0000 4011 0000 c30e 3215 > 0x0010: 59b3 c322 0035 0935 0032 c7de bb99 8182 > 0x0020: 0001 0000 0000 0001 0377 7777 0565 6d69 > 0x0030: 6c73 0363 6f6d 0000 0100 0100 0029 1000 > 0x0040: 0000 0000 0000 > 00:1c:c4:81:2f:9e > 00:00:0c:07:ac:00, ethertype IPv4 (0x0800), length 73: > 195.14.50.21.53 > 89.179.195.34.2357: 22012 ServFail 0/0/0 (31) > 0x0000: 4500 003b 84a9 0000 4011 0000 c30e 3215 > 0x0010: 59b3 c322 0035 0935 0027 3dbc 55fc 8182 > 0x0020: 0001 0000 0000 0000 0377 7777 0565 6d69 > 0x0030: 6c73 0363 6f6d 0000 0100 01 > 00:1c:c4:81:2f:9e > 00:00:0c:07:ac:00, ethertype IPv4 (0x0800), length 69: > 195.14.50.21.53 > 89.179.195.34.2357: 35869 ServFail 0/0/0 (27) > 0x0000: 4500 0037 84ac 0000 4011 0000 c30e 3215 > 0x0010: 59b3 c322 0035 0935 0023 8291 8c1d 8182 > 0x0020: 0001 0000 0000 0000 0565 6d69 6c73 0363 > 0x0030: 6f6d 0000 0100 01 > 00:1a:a1:69:35:43 > 00:1c:c4:81:2f:9e, ethertype IPv4 (0x0800), length 73: > 89.179.195.34.2357 > 195.14.50.21.53: 48025+ A? www.emils.com. (31) > 0x0000: 4500 003b 3035 0000 3811 4084 59b3 c322 > 0x0010: c30e 3215 0935 0035 0027 58a1 bb99 0100 > 0x0020: 0001 0000 0000 0000 0377 7777 0565 6d69 > 0x0030: 6c73 0363 6f6d 0000 0100 01 > 00:1c:c4:81:2f:9e > 00:00:0c:07:ac:00, ethertype IPv4 (0x0800), length 73: > 195.14.50.21.53 > 89.179.195.34.2357: 48025 ServFail 0/0/0 (31) > 0x0000: 4500 003b 84ae 0000 4011 0000 c30e 3215 > 0x0010: 59b3 c322 0035 0935 0027 d81e bb99 8182 > 0x0020: 0001 0000 0000 0000 0377 7777 0565 6d69 > 0x0030: 6c73 0363 6f6d 0000 0100 01 > > tcpdump -netxi bge0 host 78.107.71.38 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on bge0, link-type EN10MB (Ethernet), capture size 96 bytes > 00:1a:a1:69:35:43 > 00:1c:c4:81:2f:9e, ethertype IPv4 (0x0800), length 94: > 78.107.71.38.37367 > 195.14.50.21.53: 38168+ A? > nc-71-51-232-31.dhcp.embarqhsd.net. (52) > 0x0000: 4500 0050 ae4f 4000 3b11 0699 4e6b 4726 > 0x0010: c30e 3215 91f7 0035 003c e6ca 9518 0100 > 0x0020: 0001 0000 0000 0000 0f6e 632d 3731 2d35 > 0x0030: 312d 3233 322d 3331 0464 6863 7009 656d > 0x0040: 6261 7271 6873 6403 6e65 7400 0001 0001 > 00:1a:a1:69:35:43 > 00:1c:c4:81:2f:9e, ethertype IPv4 (0x0800), length 89: > 78.107.71.38.37368 > 195.14.50.21.53: 50276+ A? > 166.156.122.89.bl.spamcop.net. (47) > 0x0000: 4500 004b ae68 4000 3b11 0685 4e6b 4726 > 0x0010: c30e 3215 91f8 0035 0037 18d5 c464 0100 > 0x0020: 0001 0000 0000 0000 0331 3636 0331 3536 > 0x0030: 0331 3232 0238 3902 626c 0773 7061 6d63 > 0x0040: 6f70 036e 6574 0000 0100 01 > > Add to pf.conf > block quick from 89.179.195.34 - same, doesn't work. > > May be trouble in config? > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" From koitsu at FreeBSD.org Mon Sep 8 16:22:30 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 8 16:22:37 2008 Subject: FreeBSD 7.1-PRERELEASE Trouble In-Reply-To: <48C548A8.9030204@quis.cx> References: <9bc4ff5c0809080813t1c370b72pce80dfa64f91fa41@mail.gmail.com> <48C548A8.9030204@quis.cx> Message-ID: <20080908162227.GA73221@icarus.home.lan> On Mon, Sep 08, 2008 at 05:45:44PM +0200, Jille wrote: > Dmitry Rybin wrote: > > PF doesn't block some IP!!!! > > > > === pf.conf === > > > > ext_if="bge0" > > table { 78.107.71.38 89.179.195.34 } > > Afaik you need to separate them with a comma (,) This is incorrect. You can use a comma or a space, as the BNF grammar in pf.conf specifies. Here's the grammar break-down, one step at a time: line = ( option | pf-rule | nat-rule | binat-rule | rdr-rule | antispoof-rule | altq-rule | queue-rule | trans-anchors | anchor-rule | anchor-close | load-anchor | table-rule | ) table-rule = "table" "<" string ">" [ tableopts-list ] tableopts-list = tableopts-list tableopts | tableopts tableopts = "persist" | "const" | "file" string | "{" [ tableaddr-list ] "}" tableaddr-list = tableaddr-list [ "," ] tableaddr-spec | tableaddr-spec Note in tableaddr-list the string: [ "," ]. This means the comma is optional between items within the braces. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From fox at verio.net Mon Sep 8 18:04:15 2008 From: fox at verio.net (David DeSimone) Date: Mon Sep 8 18:04:21 2008 Subject: FreeBSD 7.1-PRERELEASE Trouble In-Reply-To: <9bc4ff5c0809080813t1c370b72pce80dfa64f91fa41@mail.gmail.com> References: <9bc4ff5c0809080813t1c370b72pce80dfa64f91fa41@mail.gmail.com> Message-ID: <20080908180407.GB4100@verio.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dmitry Rybin wrote: > > PF doesn't block some IP!!!! > > === pf.conf === > > ext_if="bge0" > table { 78.107.71.38 89.179.195.34 } > > block quick from > pass out > pass in > === pf.conf === > > # pfctl -e -f /etc/pf.conf > > # tcpdump -netxi bge0 host 89.179.195.34 > 00:1a:a1:69:35:43 > 00:1c:c4:81:2f:9e, ethertype IPv4 (0x0800), length 69: > 89.179.195.34.2357 > 195.14.50.21.53: 35869+ A? emils.com. (27) > 0x0000: 4500 0037 3034 0000 3811 4089 59b3 c322 > 0x0010: c30e 3215 0935 0035 0023 0314 8c1d 0100 > 0x0020: 0001 0000 0000 0000 0565 6d69 6c73 0363 > 0x0030: 6f6d 0000 0100 01 Even if PF causes the packet to be dropped, it will still show up on your inbound interface. You cannot prevent the packet from being sent to you unless you block it further upstream. - -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFIxWkXFSrKRjX5eCoRApOkAJ9q/Ndg9Wrcfnss//PcD1lePdCGVQCfRAja 5ltkyqIlojWZzzto7PQNRNI= =c8Ig -----END PGP SIGNATURE----- This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From koitsu at FreeBSD.org Mon Sep 8 18:50:39 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 8 18:50:46 2008 Subject: FreeBSD 7.1-PRERELEASE Trouble In-Reply-To: <20080908180407.GB4100@verio.net> References: <9bc4ff5c0809080813t1c370b72pce80dfa64f91fa41@mail.gmail.com> <20080908180407.GB4100@verio.net> Message-ID: <20080908185035.GA76018@icarus.home.lan> On Mon, Sep 08, 2008 at 01:04:07PM -0500, David DeSimone wrote: > Dmitry Rybin wrote: > > > > PF doesn't block some IP!!!! > > > > === pf.conf === > > > > ext_if="bge0" > > table { 78.107.71.38 89.179.195.34 } > > > > block quick from > > pass out > > pass in > > === pf.conf === > > > > # pfctl -e -f /etc/pf.conf > > > > # tcpdump -netxi bge0 host 89.179.195.34 > > 00:1a:a1:69:35:43 > 00:1c:c4:81:2f:9e, ethertype IPv4 (0x0800), length 69: > > 89.179.195.34.2357 > 195.14.50.21.53: 35869+ A? emils.com. (27) > > 0x0000: 4500 0037 3034 0000 3811 4089 59b3 c322 > > 0x0010: c30e 3215 0935 0035 0023 0314 8c1d 0100 > > 0x0020: 0001 0000 0000 0000 0565 6d69 6c73 0363 > > 0x0030: 6f6d 0000 0100 01 > > Even if PF causes the packet to be dropped, it will still show up on > your inbound interface. You cannot prevent the packet from being sent > to you unless you block it further upstream. I was going to reply with the same thing, but aborted -- his tcpdump shows *bidirectional* traffic, both from the bad host and *to* to the bad host. OP's server is replying to the packet which pf has supposedly blocked. This is why I think it's a state tracking thing and he might need to use -k. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Tue Sep 9 06:10:49 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Sep 9 06:10:56 2008 Subject: FreeBSD 7.1-PRERELEASE Trouble In-Reply-To: <9bc4ff5c0809082220v42bd264dp21088a15d3eb6319@mail.gmail.com> References: <9bc4ff5c0809080813t1c370b72pce80dfa64f91fa41@mail.gmail.com> <20080908180407.GB4100@verio.net> <20080908185035.GA76018@icarus.home.lan> <9bc4ff5c0809082220v42bd264dp21088a15d3eb6319@mail.gmail.com> Message-ID: <20080909061045.GA88034@icarus.home.lan> On Tue, Sep 09, 2008 at 09:20:20AM +0400, Dmitry Rybin wrote: > === pf.conf === > ext_if="bge0" > > block in quick from > pass out > pass in > === pf.conf === > # pfctl -f > # pfctl -t dnsflood -Tadd 78.107.71.38 > # pfctl -t dnsflood -Tadd 89.179.195.34 > # pfctl -t dnsflood -Tshow > 78.107.71.38 > 89.179.195.34 > > and so on. > # pfctl -k 78.107.71.38 > killed 1 states from 1 sources and 0 destinations > [root@earth /opt/home/kirgudu]# tcpdump -ibge0 -p -n host 78.107.71.38 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on bge0, link-type EN10MB (Ethernet), capture size 96 bytes > 09:12:37.260545 IP 78.107.71.38.46316 > 195.14.50.21.53: 21852+ TXT? > 170.225.6.117.bl.spamcop.net. (46) > 09:12:37.812533 IP 78.107.71.38.46317 > 195.14.50.21.53: 52423+ PTR? > 142.220.10.10.in-addr.arpa. (44) > 09:12:38.838395 IP 195.14.50.21.53 > 78.107.71.38.42859: 13664 ServFail > 0/0/0 (46) > 09:12:38.838420 IP 195.14.50.21.53 > 78.107.71.38.42859: 6698 ServFail 0/0/0 > (46) > 09:12:39.028347 IP 78.107.71.38.46318 > 195.14.50.21.53: 3221+ PTR? > 109.220.10.10.in-addr.arpa. (44) > 09:12:39.492471 IP 78.107.71.38.46319 > 195.14.50.21.53: 1887+ PTR? > 57.63.8.58.in-addr.arpa. (41) > > # pfctl -s state|grep 78.107.71.38 > all udp 195.14.50.21:53 -> 78.107.71.38:42859 MULTIPLE:MULTIPLE > > DNS service replying to the blocked host. > > # pfctl -s rules > block drop quick in on bge0 inet from to any > pass in all flags S/SA keep state > pass out all flags S/SA keep state Hmm, it appears that even with the "block" rule in place, and all previous state table entries flushed, the packet is somehow making it through. Does "pfctl -T show -t dnsflood -v" shows any hits for In/Block hits on the table entry for 78.107.71.38? (I doubt it, but I want to make sure). Only two ideas I have left: 1) Are you *absolutely sure* the packets are arriving on bge0 and not some other interface? 2) Is pf processing even enabled? pfctl -s info | head -1 Also, you removed the freebsd-pf mailing list from your response to me. I don't know why, so I've re-added it. If none of the above helps, then I'm out of ideas and David or Max will have to assist in figuring out the root cause. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From fox at verio.net Tue Sep 9 16:35:26 2008 From: fox at verio.net (David DeSimone) Date: Tue Sep 9 16:35:33 2008 Subject: FreeBSD 7.1-PRERELEASE Trouble In-Reply-To: <20080909061045.GA88034@icarus.home.lan> References: <9bc4ff5c0809080813t1c370b72pce80dfa64f91fa41@mail.gmail.com> <20080908180407.GB4100@verio.net> <20080908185035.GA76018@icarus.home.lan> <9bc4ff5c0809082220v42bd264dp21088a15d3eb6319@mail.gmail.com> <20080909061045.GA88034@icarus.home.lan> Message-ID: <20080909163518.GF4571@verio.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeremy Chadwick wrote: > > > # pfctl -k 78.107.71.38 > > killed 1 states from 1 sources and 0 destinations > > # pfctl -s state|grep 78.107.71.38 > > all udp 195.14.50.21:53 -> 78.107.71.38:42859 MULTIPLE:MULTIPLE > Hmm, it appears that even with the "block" rule in place, and all > previous state table entries flushed, the packet is somehow making it > through. I know my reading comprehension on this thread hasn't been very good, but I'm going to try again. pfctl -k did kill a state, but it appears that a reply packet from 195.14.50.21 recreated a state entry, probably just bad timing. You should try killing the state again, perhaps with pfctl -k 195.14.50.21 -k 78.107.71.38 And maybe before that, add an extra block rule in the opposite direction to block replies, at least temporarily just to stop these state entries from being recreated. - -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFIxqXFFSrKRjX5eCoRAqPGAJ9NuZHrFuridRMSDmLOIQlld0VfIACfX9Hx b5woCHBRpAu2wouD84vXqB8= =Pmof -----END PGP SIGNATURE----- This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From peter at allicient.co.uk Tue Sep 9 23:48:12 2008 From: peter at allicient.co.uk (Peter Maxwell) Date: Tue Sep 9 23:48:19 2008 Subject: pf not creating state on cloned local interface (with FreeBSD jail) Message-ID: <7731938b0809091615i6a9624fape21e0711cbbde447@mail.gmail.com> Hi, Looking for anyone's help on this: I'm not sure if pf's behaviour is correct, if its a bug, if it is working correctly, or if I'm just trying to do something that really shouldn't be done. Anyway, my setup and issue is as follows: Kernel is GENERIC 7.0-STABLE #1, amd64 with IPSEC and ALTQ options added. There is one external interface and I've created a series of cloned interfaces; lo1, lo2, lo3,,,, lox; each assigned IP 10.0.x.1/24 where the x is the same as the cloned interface number. There are no other 10. addresses in the routing table. I felt it was preferable to create cloned interfaces rather than aliased IPs on lo0 for the jails (i.e. I didn't want any possibilty of the jailed services being able to access a host service on lo0). I don't have, and wouldn't be able to justify enough public addresses for this. The salient parts of my pf.conf (very much condensed) are set state-policy if-bound scrub all antispoof on re0 (external interface) set skip on lo0 There are processes (e.g. apache) in each of the jails binding to each of the 10.0.x.1 IP addresses. Now here's the crunch... when I add a "set skip on lo?" for each of the cloned interfaces all is good and well, each of the services can talk to each other and I can add appropriate NAT rules to allow access out to the internet. However, I want to prevent general network access across the cloned interfaces (and hence jails), i.e I want to give apache access to mysql, say, but not to the smtp server. So the extra "set skip lo?" lines are removed and only "set skip lo0" remains. Which then requires creation of appropriate rules. If I try and setup rules to allow access from the main host into a jailed service (keeping it simple to start with), it seems to require two rules (one to pass in, the other to pass out - i.e. its not keeping state). If I take the example of apache running on 10.0.3.1 (lo3) in a jail, the necessary rules to allow access from the host system (i.e. not from another jail) is: pass in log on lo3 proto tcp from any to any flags S/SA modulate state pass out log on lo3 proto tcp from any to any flags S/SA modulate state I know the rules are a bit general, but that's shouldn't be important just now. If I take a look at the logs for apache the source IP for the incoming packets are 10.0.3.1 (the jail IP, the same IP as apache is running on), which I'm guessing is the standard behaviour (have done a rdr test with the "set skip" lines in place from an external IP and it takes the appropriate source address in that scenario). If the "pass out" is removed, an "Operation not permitted" error is generated (which is sort of what I expected). If the "pass in" rule is omitted then it just stalls (which really is not what I expected). If tcpdump is ran on pflog0, you cannot see the expected initial SYN packets and all you can see is a load of SYN/ACKs getting blocked. When both rules are in place and I check the output of "pfctl -s r" there is something like (and it seems to work): lo3 tcp 10.0.3.1:63167 -> 10.0.3.1:80 ESTABLISHED:ESTABLISHED lo3 tcp 10.0.3.1:80 <- 10.0.3.1:63167 ESTABLISHED:ESTABLISHED which says to me there's two state entries been created where there should only be one, that being the first line (and that I should also expect some nasty problems down the line if I leave it like that). Should the first "pass out" rule not be enough to create a state entry from which the return packets get matched? If I add a "set skip" for every cloned interface except lo3, then similar behaviour is seen - two rules are needed. Any help or advice is appreciated. Cheers, Peter From fox at verio.net Wed Sep 10 16:58:40 2008 From: fox at verio.net (David DeSimone) Date: Wed Sep 10 16:58:47 2008 Subject: pf not creating state on cloned local interface (with FreeBSD jail) In-Reply-To: <7731938b0809091615i6a9624fape21e0711cbbde447@mail.gmail.com> References: <7731938b0809091615i6a9624fape21e0711cbbde447@mail.gmail.com> Message-ID: <20080910165831.GC5570@verio.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Maxwell wrote: > > pass in log on lo3 proto tcp from any to any flags S/SA modulate state > pass out log on lo3 proto tcp from any to any flags S/SA modulate state I have heard it mentioned several times on this list (and experienced it myself) that "modulate state" does not work. But I don't really know why it doesn't work, and what behavior you should expect if you attempt to use it. I would suggest you try "keep state" instead, before proceeding further. - -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFIx/y3FSrKRjX5eCoRApccAJ492tm3v/SlPBTH0gXduuRZeS857ACeO+/G yfF/1KpNN9H4EmzU49P7SO0= =DH6a -----END PGP SIGNATURE----- This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From linimon at FreeBSD.org Sat Sep 13 10:05:21 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Sep 13 10:05:32 2008 Subject: kern/127345: [pf] Problem with PF on FreeBSD7.0 [regression] Message-ID: <200809131005.m8DA5K4Q009852@freefall.freebsd.org> Old Synopsis: Problem with PF on FreeBSD7.0 New Synopsis: [pf] Problem with PF on FreeBSD7.0 [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Sat Sep 13 10:04:14 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127345 From the.real.david.allen at gmail.com Sun Sep 14 01:47:38 2008 From: the.real.david.allen at gmail.com (David Allen) Date: Sun Sep 14 01:47:44 2008 Subject: Writing DMZ rulesets Message-ID: <2daa8b4e0809131814x5d396199x81f6167e8b766fd8@mail.gmail.com> Apologies if this question falls into the obvious category, but I'm wondering how rulesets are/should be written for DMZ scenarios. For example: ext_if = "fxp0" dmz_if = "fxp1" int_if = "fxp2" nameservers = "{ 192.168.1.2, 192.168.1.3 }" pass in on $ext_if { tcp, udp } from any to $nameservers port 53 pass out on $dmz_if { tcp, udp } from any to $nameservers port 53 pass in on $dmz_if { tcp, udp } from $nameservers port 53 to any pass in on $dmz_if { tcp, udp } from $nameservers to any port 53 pass out on $ext_if { tcp, udp } from $nameservers port 53 to any pass out on $ext_if { tcp, udp } from $nameservers to any port 53 Am I being redundant or excessively restrictive? And assuming that "keep state" is implicit, does this mean that a state entry will be created for each interface? Thanks. From bugmaster at FreeBSD.org Mon Sep 15 15:18:53 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 15 15:20:31 2008 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200809151518.m8FFIqjF018977@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/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/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 kern/82271 pf [pf] cbq scheduler cause bad latency 20 problems total. From remko at FreeBSD.org Wed Sep 17 13:07:20 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Wed Sep 17 13:07:28 2008 Subject: kern/127439: [pf]: deadlock in pf Message-ID: <200809171307.m8HD7KA1077322@freefall.freebsd.org> Old Synopsis: deadlock in pf New Synopsis: [pf]: deadlock in pf Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: remko Responsible-Changed-When: Wed Sep 17 13:06:54 UTC 2008 Responsible-Changed-Why: Reassign to PF team http://www.freebsd.org/cgi/query-pr.cgi?pr=127439 From mainland at apeiron.net Wed Sep 17 16:30:05 2008 From: mainland at apeiron.net (Geoffrey Mainland) Date: Wed Sep 17 16:30:12 2008 Subject: kern/127439: deadlock in pf Message-ID: <200809171630.m8HGU4sS093937@freefall.freebsd.org> The following reply was made to PR kern/127439; it has been noted by GNATS. From: Geoffrey Mainland To: Christian Peron Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: kern/127439: deadlock in pf Date: Wed, 17 Sep 2008 12:21:15 -0400 Sure, attached below. ext_if = "fxp0" int_if = "em0" wifi_if = "vr0" vpn_if = "tun0" rfc1918_nets = "{ 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 }" ext_net = "{ 68.164.219.97/24 }" int_net = "{ 192.168.0.0/24 }" wifi_net = "{ 192.168.1.0/24 }" vpn_net = "{ 192.168.2.0/24 }" ext_zeno = 68.164.219.98 ext_hamilton = 68.164.219.99 ext_anaximander = 68.164.219.100 ext_laplace = 68.164.219.100 ext_hilbert = 68.164.219.101 ext_nat = $ext_zeno int_zeno = 192.168.0.10 int_hamilton = 192.168.0.11 int_anaximander = 192.168.0.12 int_laplace = 192.168.0.13 int_hilbert = 192.168.0.16 int_vince = $int_anaximander wifi_gateway = 192.168.1.1 wifi_laplace = 192.168.1.13 icmp_types = "echoreq" # Supposedly 384Kb up, 1.5Mb down. We set the bandwidth to 300Kbps to get the # best performance out of the TCP ACK queue. upstream = 300Kb downstream = 1.5Mb # # Common ports # ssh_ports = "{ ssh }" http_ports = "{ http, https }" vpn_ports = "{ 1194 }" mysqld_ports = "{ 3306 }" # AIM: 5190 # MSN: 1863, 6891-6900 for file transfers # Yahoo: 5050, webcam 5100 # Jabber: 5222, 5269 aim_ports = "{ 5190 }" yahoo_ports = "{ 5050, 5100 }" msn_ports = "{ 1863 }" emule_tcp_ports = "{ 4662 }" emule_udp_ports = "{ 4662, 4665, 4672 }" bittorrent_ports = "{ 3724, 6112, 6881:6999, 46300:46400}" realplayer_ports = "{ 7070 }" battlenet_ports = "{ 6112:6119 }" nwn_ports = "{ 1070:3000, 5120:5300, 6500, 27900, 28900 }" gamespy_ports = "{ 6667, 3783, 27900, 28900, 29900, 29901, 13139, 6515, 6500, 6501 }" directx_ports = "{ 47624, 6073, 2300:2400 }" ts_tcp_ports = "{ 14534, 51234 }" ts_udp_ports = "{ 8767:8768 }" ################################################################################ # Options # ################################################################################ set block-policy return set loginterface $ext_if ################################################################################ # Normalization # ################################################################################ scrub in all ################################################################################ # # Queueing # ################################################################################ #altq on $ext_if priq bandwidth $upstream queue \ # { std_out, im_out, ssh_out, dns_out, tcp_ack_out } #queue std_out priq(default) #queue im_out priority 4 priq(red) #queue ssh_out priority 5 priq(red) #queue dns_out priority 6 #queue tcp_ack_out priority 7 #altq on $int_if cbq bandwidth 100% queue \ # { all_in } #queue all_in bandwidth 100% { int_in, ext_in } # queue int_in bandwidth 8Mb cbq(default) # queue ext_in bandwidth $downstream {std_in, im_in, ssh_in, dns_in, vince_in } # queue std_in bandwidth 500Kb cbq(borrow) # queue im_in bandwidth 100Kb priority 4 # queue ssh_in bandwidth 100Kb priority 5 # queue dns_in bandwidth 100Kb priority 6 # queue vince_in bandwidth 100Kb cbq(borrow) ################################################################################ # Translation # ################################################################################ # cantor rdr pass on $ext_if proto tcp from any to $ext_zeno port 47000:48000 -> 192.168.0.39 port 47000:* # hamilton rdr on $int_if proto tcp from any to $ext_hamilton -> $int_hamilton binat on $ext_if from $int_hamilton to any -> $ext_hamilton # anaximander rdr on $int_if proto tcp from any to $ext_anaximander -> $int_anaximander binat on $ext_if from $int_anaximander to any -> $ext_anaximander # laplace #rdr on $int_if proto tcp from any to $ext_laplace -> $int_laplace #binat on $ext_if from $int_laplace to any -> $ext_laplace # hilbert rdr on $int_if proto tcp from any to $ext_hilbert -> $int_hilbert binat on $ext_if from $int_hilbert to any -> $ext_hilbert nat on $ext_if from $int_if:network -> $ext_nat nat on $ext_if from $vpn_net -> $ext_nat # wifi nat on $ext_if from $wifi_if:network -> $ext_nat # NAT and FTP #rdr on $int_if proto tcp from any to any port ftp -> 127.0.0.1 port 8021 ################################################################################ # Filtering # ################################################################################ # # Block by default # block quick on $ext_if proto {udp, tcp} from any to any \ port { 135, 139, 445 } block log all # # Blacklist # #block quick from 194.139.33.69 to any # # Whitelist # whitelist = "{ 140.247.60.67 }" pass quick inet proto tcp from $whitelist to any \ flags S/SA keep state pass quick inet proto udp from $whitelist to any \ keep state # # Allow anything on the loopback interface # pass quick on lo0 all # # RFC 1918 addresses should not be seen on the external interface # block drop in quick on $ext_if from $rfc1918_nets to any block drop out quick on $ext_if from any to $rfc1918_nets # # Protect against spoofing # antispoof for lo0 antispoof for $ext_if antispoof for $int_if antispoof for $wifi_if antispoof for $vpn_if # # Ports we open for zeno # # Mail and news pass in on $ext_if inet proto tcp from any to ($ext_if) \ port { smtp, smtps, submission, imaps, nntps, auth } \ flags S/SA keep state \ #queue std_in # auth pass in on $ext_if inet proto tcp from any to ($ext_if) \ port { auth } \ flags S/SA keep state \ #queue std_in # HTTP pass in on $ext_if inet proto tcp from any to ($ext_if) \ port $http_ports \ flags S/SA keep state \ #queue std_in # VPN pass in on $ext_if inet proto tcp from any to ($ext_if) \ port $vpn_ports \ flags S/SA keep state \ #queue std_in pass in on $ext_if inet proto udp from any to ($ext_if) \ port $vpn_ports \ keep state \ #queue std_in # SSH pass in on $ext_if inet proto tcp from any to ($ext_if) \ port $ssh_ports \ flags S/SA keep state \ #queue(std_in, ssh_in) # FTP pass in on $ext_if proto tcp from any to ($ext_if) \ port ftp keep state \ #queue std_in pass in on $ext_if proto tcp from any to ($ext_if) \ port > 49151 keep state \ #queue std_in # TeamSpeak pass in on $ext_if inet proto tcp from any to ($ext_if) \ port $ts_tcp_ports \ flags S/SA keep state pass in on $ext_if inet proto udp from any to ($ext_if) \ port $ts_udp_ports \ keep state # DNS pass out on $ext_if inet proto { tcp udp } from ($ext_if) to any port domain \ modulate state \ #queue dns_out # # Ports we open up for everyone # # ssh pass in on $ext_if inet proto tcp from any to $int_net \ port $ssh_ports \ flags S/SA keep state pass out on $ext_if inet proto tcp from ($ext_if) to any \ port $ssh_ports \ flags S/SA modulate state \ #queue(std_out, ssh_out) # FTP pass in on $ext_if inet proto tcp from any to $ext_nat \ user proxy flags S/SA modulate state # AIM pass in on $ext_if inet proto tcp from any to $int_net \ port $aim_ports \ flags S/SA keep state pass in on $ext_if inet proto udp from any to $int_net \ port $aim_ports \ keep state pass out on $ext_if inet proto tcp from ($ext_if) to any \ port $aim_ports \ flags S/SA keep state \ #queue(im_out, tcp_ack_out) pass out on $ext_if inet proto udp from ($ext_if) to any \ port $aim_ports \ modulate state \ #queue(im_out) # Yahoo pass in on $ext_if inet proto tcp from any to $int_net \ port $yahoo_ports \ flags S/SA keep state pass in on $ext_if inet proto udp from any to $int_net \ port $yahoo_ports \ keep state pass out on $ext_if inet proto tcp from ($ext_if) to any \ port $yahoo_ports \ flags S/SA modulate state \ #queue(im_out, tcp_ack_out) # emule pass in on $ext_if inet proto tcp from any to $int_net \ port $emule_tcp_ports \ flags S/SA keep state pass in on $ext_if inet proto udp from any to $int_net \ port $emule_udp_ports \ modulate state # BitTorrent pass in on $ext_if inet proto tcp from any to $int_net \ port $bittorrent_ports \ flags S/SA keep state pass in on $ext_if inet proto udp from any to $int_net \ port $bittorrent_ports \ keep state # Realplayer pass in on $ext_if inet proto udp from any to $int_net \ port $realplayer_ports \ keep state # Battlenet pass in on $ext_if inet proto tcp from any to $int_net \ port $battlenet_ports \ flags S/SA keep state # Neverwinter Nights #pass in on $ext_if inet proto udp from any to $int_net \ # port $nwn_ports \ # keep state # Gamespy Arcade #pass in on $ext_if inet proto tcp from any to $int_net \ # port $gamespy_ports \ # flags S/SA keep state # DirectX Gaming #pass in on $ext_if inet proto tcp from any to $int_net \ # port $directx_ports \ # flags S/SA keep state # MySQL pass in on $ext_if inet proto tcp from any to ($ext_if) \ port $mysqld_ports flags S/SA keep state \ # # ICMP # pass in inet proto icmp all icmp-type $icmp_types keep state # # Allow traffic to flow freely between firewall and internal network # pass in on $int_if from $int_if:network to any keep state pass out on $int_if from any to $int_if:network modulate state #pass out on $int_if from any to $int_vince modulate state \ # #queue(vince_in) # # Allow traffic to flow freely between firewall and wifi network # pass in on $wifi_if from $wifi_if:network to any keep state pass out on $wifi_if from any to $wifi_if:network modulate state #pass in on $wifi_if inet proto udp from $wifi_if:network \ # to {$ext_zeno, $wifi_gateway} port 1194 \ # keep state #pass out on $wifi_if inet proto udp from {$ext_zeno, $wifi_gateway} port 1194 \ # to $wifi_if:network \ # modulate state # # Allow traffic to flow freely between firewall and vpn network # pass in on $vpn_if from $vpn_net to any keep state pass out on $vpn_if from any to $vpn_net modulate state # # Allow all outgoing traffic from the firewall to the external network # pass out on $ext_if proto tcp all flags S/SA modulate state \ #queue(std_out, tcp_ack_out) pass out on $ext_if proto { udp, icmp } all keep state # # IPv6 # pass out quick proto ipv6 from any to any keep state pass out quick proto ipv6-icmp from any to any keep state From csjp at freebsd.org Wed Sep 17 16:50:05 2008 From: csjp at freebsd.org (Christian Peron) Date: Wed Sep 17 16:50:21 2008 Subject: kern/127439: deadlock in pf Message-ID: <200809171650.m8HGo5gv096228@freefall.freebsd.org> The following reply was made to PR kern/127439; it has been noted by GNATS. From: Christian Peron To: Geoffrey Mainland Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: kern/127439: deadlock in pf Date: Wed, 17 Sep 2008 11:16:01 -0500 Can you provide a copy of your pf ruleset? On Wed, Sep 17, 2008 at 08:33:23AM -0400, Geoffrey Mainland wrote: > > >Number: 127439 > >Category: kern > >Synopsis: deadlock in pf > >Confidential: no > >Severity: critical > >Priority: high > >Responsible: freebsd-bugs > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Wed Sep 17 12:50:01 UTC 2008 > >Closed-Date: > >Last-Modified: > >Originator: Geoffrey Mainland > >Release: FreeBSD 7.1-PRERELEASE i386 > >Organization: > >Environment: > System: FreeBSD zeno.apeiron.net 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #7: Tue Sep 16 09:28:16 EDT 2008 toor@zeno.apeiron.net:/usr/obj/usr/src/sys/ZENO i386 > > > >Description: > > This happens reliably every night. I'm not sure what's running that triggers it. > > ifconfig: > > em0: flags=8843 metric 0 mtu 1500 > options=9b > ether 00:0e:0c:5f:c1:f8 > inet6 fe80::20e:cff:fe5f:c1f8%em0 prefixlen 64 scopeid 0x1 > inet 192.168.0.10 netmask 0xffffff00 broadcast 192.168.0.255 > inet 192.168.0.1 netmask 0xffffffff broadcast 192.168.0.1 > inet 192.168.0.2 netmask 0xffffffff broadcast 192.168.0.2 > media: Ethernet autoselect (100baseTX ) > status: active > fxp0: flags=8843 metric 0 mtu 1500 > options=8 > ether 00:90:27:62:87:4d > inet6 fe80::290:27ff:fe62:874d%fxp0 prefixlen 64 scopeid 0x2 > inet 68.164.219.98 netmask 0xfffffff8 broadcast 68.164.219.103 > inet 68.164.219.99 netmask 0xffffffff broadcast 68.164.219.99 > inet 68.164.219.100 netmask 0xffffffff broadcast 68.164.219.100 > inet 68.164.219.101 netmask 0xffffffff broadcast 68.164.219.101 > media: Ethernet autoselect (100baseTX ) > status: active > vr0: flags=8843 metric 0 mtu 1500 > options=2808 > ether 00:15:f2:43:48:7b > inet6 fe80::215:f2ff:fe43:487b%vr0 prefixlen 64 scopeid 0x3 > inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 > inet 192.168.1.2 netmask 0xffffffff broadcast 192.168.1.2 > media: Ethernet autoselect (none) > status: no carrier > lo0: flags=8049 metric 0 mtu 16384 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 > inet 127.0.0.1 netmask 0xff000000 > pfsync0: flags=0<> metric 0 mtu 1460 > syncpeer: 224.0.0.240 maxupd: 128 > pflog0: flags=0<> metric 0 mtu 33204 > gif0: flags=8051 metric 0 mtu 1280 > tunnel inet 68.164.219.98 --> 66.55.128.25 > inet6 fe80::20e:cff:fe5f:c1f8%gif0 prefixlen 64 scopeid 0x7 > inet6 2001:4830:1200:10b::2 --> 2001:4830:1200:10b::1 prefixlen 128 > tun0: flags=8051 metric 0 mtu 1500 > inet6 fe80::20e:cff:fe5f:c1f8%tun0 prefixlen 64 scopeid 0x8 > inet 192.168.2.1 --> 192.168.2.2 netmask 0xffffffff > Opened by PID 1454 > > Kernel config: > > cpu I686_CPU > ident ZENO > options SCHED_ULE > options SMP > options PREEMPTION > options DEVICE_POLLING > options HZ=2000 > options _KPOSIX_PRIORITY_SCHEDULING > options P1003_1B_MQUEUE > options KDB > options KDB_TRACE > options DDB > options WITNESS > options INVARIANTS > options INVARIANT_SUPPORT > makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols > options COMPAT_FREEBSD4 > options COMPAT_FREEBSD5 > options COMPAT_FREEBSD6 > options SYSVSHM > options SYSVSEM > options SYSVMSG > options STACK > options INET #Internet communications protocols > options INET6 #IPv6 communications protocols > options IPSEC #IP security (requires device crypto) > options NETATALK #Appletalk communications protocols > options NETSMB #SMB/CIFS requester > options LIBMCHAIN > options SCTP > options NETGRAPH # netgraph(4) system > device ether #Generic Ethernet > device loop #Network loopback device > device bpf #Berkeley packet filter > device tap #Virtual Ethernet driver > device tun #Tunnel driver (ppp(8), nos-tun(8)) > device gre #IP over IP tunneling > device pf #PF OpenBSD packet-filter firewall > device pflog #logging support interface for PF > device pfsync #synchronization interface for PF > device gif #IPv6 and IPv4 tunneling > device faith #for IPv6 and IPv4 translation > device stf #6to4 IPv6 over IPv4 encapsulation > options FFS #Fast filesystem > options NFSCLIENT #Network File System client > options CD9660 #ISO 9660 filesystem > options MSDOSFS #MS DOS File System (FAT, FAT32) > options NFSSERVER #Network File System server > options NFSLOCKD #Network Lock Manager > options NTFS #NT File System > options PROCFS #Process filesystem (requires PSEUDOFS) > options PSEUDOFS #Pseudo-filesystem framework > options SMBFS #SMB/CIFS filesystem > options UDF #Universal Disk Format > options NFS_ROOT #NFS usable as root device > options SOFTUPDATES > options UFS_ACL > options UFS_DIRHASH > device random > device mem > options AUDIT > device scbus #base SCSI code > device da #SCSI direct access devices (aka disks) > device cd #SCSI CD-ROMs > device pt #SCSI processor > device pass #CAM passthrough driver > device pty #Pseudo ttys > device md #Memory/malloc disk > options LIBICONV > options KBD_INSTALL_CDEV # install a CDEV entry in /dev > device splash # Splash screen and screen saver support > device sc > options SC_DISABLE_KDBKEY # disable `debug' key > device ata > device atadisk # ATA disk drives > device ataraid # ATA RAID drives > device atapicd # ATAPI CDROM drives > device atapifd # ATAPI floppy drives > device atapicam # emulate ATAPI devices as SCSI ditto via CAM > options ATA_STATIC_ID > device fdc > device sound > device ppc > device ppbus > device lpt > device ppi > device uhci > device ehci > device usb > device crypto # core crypto support > device cryptodev # /dev/crypto for access to h/w > device apic # I/O apic > device nvram # Access to rtc cmos via /dev/nvram > device sio > device eisa > device pci > options VESA > device psm > device atkbdc > device atkbd > device vga > options COMPAT_LINUX > options COMPAT_AOUT > options LINPROCFS > options LINSYSFS > > > > > > dmesg output (after crash): > > Copyright (c) 1992-2008 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.1-PRERELEASE #7: Tue Sep 16 09:28:16 EDT 2008 > toor@zeno.apeiron.net:/usr/obj/usr/src/sys/ZENO > WARNING: WITNESS option enabled, expect reduced performance. > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Sempron(tm) Processor 3100+ (1800.09-MHz 686-class CPU) > Origin = "AuthenticAMD" Id = 0x10fc0 Stepping = 0 > Features=0x78bfbff > AMD Features=0xc2500800 > AMD Features2=0x1 > real memory = 1073414144 (1023 MB) > avail memory = 1040887808 (992 MB) > WITNESS: spin lock cpuset not in order list > WITNESS: spin lock intrcnt not in order list > netsmb_dev: loaded > cryptosoft0: on motherboard > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, 3fef0000 (3) failed > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: mem > 0xfb000000-0xfbffffff,0xf0000000-0xf7ffffff irq 11 at device 0.0 on pci1 > em0: port 0xe800-0xe83f mem > 0xfae00000-0xfae1ffff,0xfad00000-0xfad1ffff irq 11 at device 11.0 on pci0 > em0: [FILTER] > em0: Ethernet address: 00:0e:0c:5f:c1:f8 > fxp0: port 0xe400-0xe43f mem > 0xfab00000-0xfab00fff,0xfaa00000-0xfaafffff irq 10 at device 12.0 on pci0 > miibus0: on fxp0 > inphy0: PHY 1 on miibus0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fxp0: Ethernet address: 00:90:27:62:87:4d > fxp0: [ITHREAD] > atapci0: port > 0xe000-0xe007,0xd800-0xd803,0xd400-0xd407,0xd000-0xd003,0xc800-0xc80f,0xc400-0xc4ff > irq 10 at device 15.0 on pci0 > atapci0: [ITHREAD] > ata2: on atapci0 > ata2: [ITHREAD] > ata3: on atapci0 > ata3: [ITHREAD] > atapci1: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 15.1 on pci0 > ata0: on atapci1 > ata0: [ITHREAD] > ata1: on atapci1 > ata1: [ITHREAD] > uhci0: port 0xb000-0xb01f irq 11 at device 16.0 on > pci0 > uhci0: [GIANT-LOCKED] > uhci0: [ITHREAD] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 2 ports with 2 removable, self powered > uhci1: port 0xb400-0xb41f irq 11 at device 16.1 on > pci0 > uhci1: [GIANT-LOCKED] > uhci1: [ITHREAD] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: on usb1 > uhub1: 2 ports with 2 removable, self powered > uhci2: port 0xb800-0xb81f irq 10 at device 16.2 on > pci0 > uhci2: [GIANT-LOCKED] > uhci2: [ITHREAD] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: on usb2 > uhub2: 2 ports with 2 removable, self powered > uhci3: port 0xc000-0xc01f irq 10 at device 16.3 on > pci0 > uhci3: [GIANT-LOCKED] > uhci3: [ITHREAD] > usb3: on uhci3 > usb3: USB revision 1.0 > uhub3: on usb3 > uhub3: 2 ports with 2 removable, self powered > ehci0: mem 0xfa700000-0xfa7000ff irq 5 at device > 16.4 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb4: EHCI version 1.0 > usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 > usb4: on ehci0 > usb4: USB revision 2.0 > uhub4: on usb4 > uhub4: 8 ports with 8 removable, self powered > isab0: at device 17.0 on pci0 > isa0: on isab0 > pci0: at device 17.5 (no driver attached) > vr0: port 0xa400-0xa4ff mem > 0xfa600000-0xfa6000ff irq 11 at device 18.0 on pci0 > vr0: Quirks: 0x0 > vr0: Revision: 0x78 > miibus1: on vr0 > rlphy0: PHY 1 on miibus1 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > vr0: Ethernet address: 00:15:f2:43:48:7b > vr0: [ITHREAD] > cpu0: on acpi0 > acpi_button0: on acpi0 > acpi_button1: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on > acpi0 > fdc0: [FILTER] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > sio0: type 16550A > sio0: [FILTER] > orm0: at iomem 0xcd000-0xcdfff,0xce000-0xcefff,0xcf000-0xd3fff > pnpid ORM0000 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > ppc0: at port 0x378-0x37f irq 7 on isa0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/9 bytes threshold > ppbus0: on ppc0 > ppbus0: [ITHREAD] > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > ppc0: [GIANT-LOCKED] > ppc0: [ITHREAD] > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > Timecounter "TSC" frequency 1800086355 Hz quality 800 > Timecounters tick every 1.000 msec > IPsec: Initialized Security Association Processing. > ad0: 194481MB at ata0-master UDMA133 > acd0: DVDR at ata1-master UDMA33 > ad4: 239372MB at ata2-master SATA150 > cd0 at ata1 bus 0 target 0 lun 0 > cd0: <_NEC DVD_RW ND-3550A 1.05> Removable CD-ROM SCSI-0 device > cd0: 33.000MB/s transfers > cd0: Attempt to query device size failed: NOT READY, Medium not present > WARNING: WITNESS option enabled, expect reduced performance. > Trying to mount root from ufs:/dev/ad4s1a > WARNING: / was not properly dismounted > lock order reversal: > 1st 0xc0907fcc pf task mtx (pf task mtx) @ > /usr/src/sys/contrib/pf/net/pf_ioctl.c:1394 > 2nd 0xc0973488 ifnet (ifnet) @ /usr/src/sys/net/if.c:1558 > KDB: stack backtrace: > db_trace_self_wrapper(c088cf61,e658ba3c,c05eb7b6,c088f4ad,c0973488,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c088f4ad,c0973488,c0896cfd,c0896cfd,c0896b56,...) at > kdb_backtrace+0x29 > witness_checkorder(c0973488,9,c0896b56,616,0,...) at witness_checkorder+0x6d6 > _mtx_lock_flags(c0973488,0,c0896b56,616,c3f37a70,...) at _mtx_lock_flags+0xbc > ifunit(c3f37a70,0,c08711f2,572,c05e958e,...) at ifunit+0x2f > pfioctl(c3d2d800,c0104414,c3f37a70,3,c3f48690,...) at pfioctl+0x23b5 > devfs_ioctl_f(c3f49c2c,c0104414,c3f37a70,c3b2c000,c3f48690,...) at > devfs_ioctl_f+0xe5 > kern_ioctl(c3f48690,3,c0104414,c3f37a70,1000000,...) at kern_ioctl+0x243 > ioctl(c3f48690,e658bcfc,c,c08bade8,c08d3630,...) at ioctl+0x134 > syscall(e658bd38) at syscall+0x274 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281aac4b, esp = 0xbfbfde5c, ebp > = 0xbfbfde88 --- > lock order reversal: > 1st 0xc097830c tcp (tcp) @ /usr/src/sys/netinet/tcp_input.c:400 > 2nd 0xc09775d8 PFil hook read/write mutex (PFil hook read/write mutex) @ > /usr/src/sys/net/pfil.c:73 > KDB: stack backtrace: > db_trace_self_wrapper(c088cf61,e42579ac,c05eb7b6,c088f4ad,c09775d8,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c088f4ad,c09775d8,c0897dab,c0897dab,c0897d93,...) at > kdb_backtrace+0x29 > witness_checkorder(c09775d8,1,c0897d93,49,c08a1d09,...) at > witness_checkorder+0x6d6 > _rw_rlock(c09775d8,c0897d93,49,e4257a6c,0,...) at _rw_rlock+0x8e > pfil_run_hooks(c09775c0,e4257a8c,c3c31c00,2,0,...) at pfil_run_hooks+0x35 > ip_output(c3c46100,0,e4257a50,0,0,0,c08e7c90,0,0,0,c067c807,c08e7c94,c08e7c9c,c8) > at ip_output+0x90f > tcp_respond(0,c3c87020,c3c87034,c3c46100,2da9088c,...) at tcp_respond+0x3e7 > tcp_dropwithreset(1,3,c089c953,353,1900,...) at tcp_dropwithreset+0x152 > tcp_input(c3c46100,14,c3c31c00,1,0,...) at tcp_input+0xe45 > ip_input(c3c46100,c3c46100,800,c3c31c00,800,...) at ip_input+0x686 > netisr_dispatch(2,c3c46100,10,3,0,...) at netisr_dispatch+0x72 > ether_demux(c3c31c00,c3c46100,3,0,3,...) at ether_demux+0x2e5 > ether_input(c3c31c00,c3c46100,c0aa0a74,6a9,ffffffff,...) at ether_input+0x37f > fxp_intr_body(ffffffff,0,c0aa0a74,5db,c3c33014,...) at fxp_intr_body+0x1c4 > fxp_intr(c3c33000,0,c08866ae,4b6,c3b3c268,...) at fxp_intr+0xa0 > ithread_loop(c3c1fa50,e4257d38,c0886453,31c,c3bef2b8,...) at ithread_loop+0x1c5 > fork_exit(c0590660,c3c1fa50,e4257d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xe4257d70, ebp = 0 --- > lock order reversal: > 1st 0xc4013d44 udpinp (udpinp) @ /usr/src/sys/netinet/udp_usrreq.c:878 > 2nd 0xc09775d8 PFil hook read/write mutex (PFil hook read/write mutex) @ > /usr/src/sys/net/pfil.c:73 > KDB: stack backtrace: > db_trace_self_wrapper(c088cf61,e658ba14,c05eb7b6,c088f4ad,c09775d8,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c088f4ad,c09775d8,c0897dab,c0897dab,c0897d93,...) at > kdb_backtrace+0x29 > witness_checkorder(c09775d8,1,c0897d93,49,c08a1d09,...) at > witness_checkorder+0x6d6 > _rw_rlock(c09775d8,c0897d93,49,e658bad4,c4013ca8,...) at _rw_rlock+0x8e > pfil_run_hooks(c09775c0,e658baf4,c3d44000,2,c4013ca8,...) at pfil_run_hooks+0x35 > ip_output(c3ef6100,0,e658bab8,0,0,...) at ip_output+0x90f > udp_send(c42454e0,0,c3ef6100,0,0,...) at udp_send+0x8cd > sosend_dgram(c42454e0,0,e658bbec,c3ef6100,0,...) at sosend_dgram+0x351 > sosend(c42454e0,0,e658bbec,0,0,...) at sosend+0x54 > kern_sendit(c3f48690,4,e658bc68,0,0,...) at kern_sendit+0xdb > sendit(0,8143023,0,0,0,...) at sendit+0xb1 > sendto(c3f48690,e658bcfc,18,c08a5d78,c08d3d98,...) at sendto+0x48 > syscall(e658bd38) at syscall+0x274 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (133, FreeBSD ELF32, sendto), eip = 0x2816bc83, esp = 0xbfbfd73c, > ebp = 0xbfbfd768 --- > lock order reversal: > 1st 0xc423f150 tcpinp (tcpinp) @ /usr/src/sys/netinet/tcp_usrreq.c:472 > 2nd 0xc09775d8 PFil hook read/write mutex (PFil hook read/write mutex) @ > /usr/src/sys/net/pfil.c:73 > KDB: stack backtrace: > db_trace_self_wrapper(c088cf61,e65a3a30,c05eb7b6,c088f4ad,c09775d8,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c088f4ad,c09775d8,c0897dab,c0897dab,c0897d93,...) at > kdb_backtrace+0x29 > witness_checkorder(c09775d8,1,c0897d93,49,c08a1d09,...) at > witness_checkorder+0x6d6 > _rw_rlock(c09775d8,c0897d93,49,e65a3af0,c423f0b4,...) at _rw_rlock+0x8e > pfil_run_hooks(c09775c0,e65a3b10,c3d44000,2,c423f0b4,...) at pfil_run_hooks+0x35 > ip_output(c3c94e00,0,e65a3ad4,0,0,...) at ip_output+0x90f > tcp_output(c42421d0,c3d2bc50,1d8,c423f150,c4259000,...) at tcp_output+0x140c > tcp_usr_connect(c4259000,c3d2bc50,c3d2f8c0,25,e65a3c64,...) at > tcp_usr_connect+0x11c > soconnect(c4259000,c3d2bc50,c3d2f8c0,10,16,...) at soconnect+0x52 > kern_connect(c3d2f8c0,9,c3d2bc50,c3d2bc50,0,...) at kern_connect+0x59 > connect(c3d2f8c0,e65a3cfc,c,c088ff65,c08d3a50,...) at connect+0x46 > syscall(e65a3d38) at syscall+0x274 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (98, FreeBSD ELF32, connect), eip = 0x28161e9b, esp = 0xbfbfe71c, > ebp = 0xbfbfe868 --- > lock order reversal: > 1st 0xc3eda524 tcp_sc_head (tcp_sc_head) @ > /usr/src/sys/netinet/tcp_syncache.c:494 > 2nd 0xc09775d8 PFil hook read/write mutex (PFil hook read/write mutex) @ > /usr/src/sys/net/pfil.c:73 > KDB: stack backtrace: > db_trace_self_wrapper(c088cf61,e4257854,c05eb7b6,c088f4ad,c09775d8,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c088f4ad,c09775d8,c0897dab,c0897dab,c0897d93,...) at > kdb_backtrace+0x29 > witness_checkorder(c09775d8,1,c0897d93,49,c08a1d09,...) at > witness_checkorder+0x6d6 > _rw_rlock(c09775d8,c0897d93,49,e4257914,0,...) at _rw_rlock+0x8e > pfil_run_hooks(c09775c0,e4257934,c3c31c00,2,0,...) at pfil_run_hooks+0x35 > ip_output(c3ef7a00,0,e42578f8,0,0,...) at ip_output+0x90f > syncache_respond(c426ad70,c40c0834,0,0,c40c0834,...) at syncache_respond+0x3a2 > _syncache_add(c42400b4,e4257ba8,c40b3700,0,0,...) at _syncache_add+0x2b0 > syncache_add(e4257b68,e4257b90,c40c0834,c42400b4,e4257ba8,...) at > syncache_add+0x38 > tcp_input(c40b3700,14,c3c31c00,1,0,...) at tcp_input+0xd6b > ip_input(c40b3700,c40b3700,800,c3c31c00,800,...) at ip_input+0x686 > netisr_dispatch(2,c40b3700,10,3,0,...) at netisr_dispatch+0x72 > ether_demux(c3c31c00,c40b3700,3,0,3,...) at ether_demux+0x2e5 > ether_input(c3c31c00,c40b3700,c0aa0a74,6a9,ffffffff,...) at ether_input+0x37f > fxp_intr_body(ffffffff,0,c0aa0a74,5db,c3c33014,...) at fxp_intr_body+0x1c4 > fxp_intr(c3c33000,0,c08866ae,4b6,c3b3c268,...) at fxp_intr+0xa0 > ithread_loop(c3c1fa50,e4257d38,c0886453,31c,c3bef2b8,...) at ithread_loop+0x1c5 > fork_exit(c0590660,c3c1fa50,e4257d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xe4257d70, ebp = 0 --- > lock order reversal: > 1st 0xc09786cc udp (udp) @ /usr/src/sys/netinet/udp_usrreq.c:395 > 2nd 0xc09775d8 PFil hook read/write mutex (PFil hook read/write mutex) @ > /usr/src/sys/net/pfil.c:73 > KDB: stack backtrace: > db_trace_self_wrapper(c088cf61,e42579b8,c05eb7b6,c088f4ad,c09775d8,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c088f4ad,c09775d8,c0897dab,c0897dab,c0897d93,...) at > kdb_backtrace+0x29 > witness_checkorder(c09775d8,1,c0897d93,49,c08a1d09,...) at > witness_checkorder+0x6d6 > _rw_rlock(c09775d8,c0897d93,49,e4257a78,0,...) at _rw_rlock+0x8e > pfil_run_hooks(c09775c0,e4257a98,c3c31c00,2,0,...) at pfil_run_hooks+0x35 > ip_output(c3efae00,0,e4257a5c,0,0,...) at ip_output+0x90f > icmp_reflect(c40c6020,c3efaec8,14,c3efaf00,c40c6020,...) at icmp_reflect+0x3df > icmp_error(c40b4d00,3,3,0,0,...) at icmp_error+0x3bd > udp_input(c40b4d00,14,c3c31c00,1,0,...) at udp_input+0x5ea > ip_input(c40b4d00,c40b4d00,800,c3c31c00,800,...) at ip_input+0x686 > netisr_dispatch(2,c40b4d00,10,3,0,...) at netisr_dispatch+0x72 > ether_demux(c3c31c00,c40b4d00,3,0,3,...) at ether_demux+0x2e5 > ether_input(c3c31c00,c40b4d00,c0aa0a74,6a9,ffffffff,...) at ether_input+0x37f > fxp_intr_body(ffffffff,0,c0aa0a74,5db,c3c33014,...) at fxp_intr_body+0x1c4 > fxp_intr(c3c33000,0,c08866ae,4b6,c3b3c268,...) at fxp_intr+0xa0 > ithread_loop(c3c1fa50,e4257d38,c0886453,31c,c3bef2b8,...) at ithread_loop+0x1c5 > fork_exit(c0590660,c3c1fa50,e4257d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xe4257d70, ebp = 0 --- > > > > > > kernel backtrace: > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"... > > Unread portion of the kernel message buffer: > panic: _rw_rlock (tcp): wlock already held @ > /usr/src/sys/contrib/pf/net/pf.c:3016 > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper(c088cf61,e6846220,c05ae7df,c08b659d,0,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c08b659d,0,c0889c7e,e684622c,0,...) at kdb_backtrace+0x29 > panic(c0889c7e,c085a754,c088f55e,c087092d,bc8,...) at panic+0x10f > _rw_rlock(c097830c,c087092d,bc8,c08d9624,c087092d,...) at _rw_rlock+0x73 > pf_socket_lookup(2,e68463dc,0,cc4,3,...) at pf_socket_lookup+0x208 > pf_test_tcp(e6846444,e6846440,2,c3efee00,c3c8e900,...) at pf_test_tcp+0x142 > pf_test6(2,c3d44000,e68464a0,0,0,...) at pf_test6+0x8a0 > pf_check6_out(0,e68464a0,c3d44000,2,0,...) at pf_check6_out+0x47 > pfil_run_hooks(c097ad00,e6846638,c3d44000,2,0,...) at pfil_run_hooks+0x88 > ip6_output(c3c8e900,0,e6846618,0,0,...) at ip6_output+0x122e > pf_send_tcp(c4fcfe00,c41259b4,1c,c4fcfe5c,c4fcfe4c,...) at pf_send_tcp+0x6dd > pf_test_tcp(e68468e8,e68468e4,2,c3f20900,c4fcfe00,...) at pf_test_tcp+0xcef > pf_test6(2,c3f06400,e6846944,0,c446b7bc,...) at pf_test6+0x8a0 > pf_check6_out(0,e6846944,c3f06400,2,c446b7bc,...) at pf_check6_out+0x47 > pfil_run_hooks(c097ad00,e6846adc,c3f06400,2,c446b7bc,...) at pfil_run_hooks+0x88 > ip6_output(c4fcfe00,0,e6846abc,0,0,...) at ip6_output+0x122e > tcp_output(c45553a0,c447e7c0,201,c446b858,c45553a0,...) at tcp_output+0x137e > tcp6_usr_connect(c50cd340,c447e7c0,c4eed690,25,e6846c64,...) at > tcp6_usr_connect+0x171 > soconnect(c50cd340,c447e7c0,c4eed690,1c,16,...) at soconnect+0x52 > kern_connect(c4eed690,3,c447e7c0,c447e7c0,0,...) at kern_connect+0x59 > connect(c4eed690,e6846cfc,c,c08a288e,c08d3a50,...) at connect+0x46 > syscall(e6846d38) at syscall+0x274 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (98, FreeBSD ELF32, connect), eip = 0x282e6e9b, esp = 0xbfbfe7ec, > ebp = 0xbfbfe848 --- > KDB: enter: panic > shared rw PFil hook read/write mutex r = 1 (0xc097ad18) locked @ > /usr/src/sys/net/pfil.c:73 > exclusive rw tcpinp r = 0 (0xc446b858) locked @ > /usr/src/sys/netinet/tcp_usrreq.c:513 > exclusive rw tcp r = 0 (0xc097830c) locked @ > /usr/src/sys/netinet/tcp_usrreq.c:510 > exclusive sx so_rcv_sx r = 0 (0xc452fbec) locked @ > /usr/src/sys/kern/uipc_sockbuf.c:148 > exclusive sx so_rcv_sx r = 0 (0xc483cbec) locked @ > /usr/src/sys/kern/uipc_sockbuf.c:148 > exclusive sx so_rcv_sx r = 0 (0xc4e89bec) locked @ > /usr/src/sys/kern/uipc_sockbuf.c:148 > exclusive sx so_rcv_sx r = 0 (0xc4e8970c) locked @ > /usr/src/sys/kern/uipc_sockbuf.c:148 > exclusive sx so_rcv_sx r = 0 (0xc483c22c) locked @ > /usr/src/sys/kern/uipc_sockbuf.c:148 > exclusive sx so_rcv_sx r = 0 (0xc480d70c) locked @ > /usr/src/sys/kern/uipc_sockbuf.c:148 > exclusive sx so_rcv_sx r = 0 (0xc4e8a08c) locked @ > /usr/src/sys/kern/uipc_sockbuf.c:148 > exclusive sx so_rcv_sx r = 0 (0xc4e8a56c) locked @ > /usr/src/sys/kern/uipc_sockbuf.c:148 > exclusive sx so_rcv_sx r = 0 (0xc41a456c) locked @ > /usr/src/sys/kern/uipc_sockbuf.c:148 > exclusive sx so_rcv_sx r = 0 (0xc41c156c) locked @ > /usr/src/sys/kern/uipc_sockbuf.c:148 > exclusive sx so_rcv_sx r = 0 (0xc41c18ac) locked @ > /usr/src/sys/kern/uipc_sockbuf.c:148 > exclusive sx so_rcv_sx r = 0 (0xc41c1bec) locked @ > /usr/src/sys/kern/uipc_sockbuf.c:148 > exclusive sx so_rcv_sx r = 0 (0xc41f108c) locked @ > /usr/src/sys/kern/uipc_sockbuf.c:148 > shared rw udpinp r = 0 (0xc400f63c) locked @ > /usr/src/sys/netinet/udp_usrreq.c:878 > Uptime: 16h23m36s > Physical memory: 1015 MB > Dumping 166 MB: 151 135 119 103 87 71 55 39 23 7 > > Reading symbols from /boot/kernel/if_em.ko...Reading symbols from > /boot/kernel/if_em.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/if_em.ko > Reading symbols from /boot/kernel/if_fxp.ko...Reading symbols from > /boot/kernel/if_fxp.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/if_fxp.ko > Reading symbols from /boot/kernel/miibus.ko...Reading symbols from > /boot/kernel/miibus.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/miibus.ko > Reading symbols from /boot/kernel/if_vr.ko...Reading symbols from > /boot/kernel/if_vr.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/if_vr.ko > Reading symbols from /boot/kernel/ulpt.ko...Reading symbols from > /boot/kernel/ulpt.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/ulpt.ko > Reading symbols from /boot/kernel/accf_http.ko...Reading symbols from > /boot/kernel/accf_http.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/accf_http.ko > Reading symbols from /boot/kernel/acpi.ko...Reading symbols from > /boot/kernel/acpi.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/acpi.ko > #0 doadump () at pcpu.h:196 > 196 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:196 > #1 0xc05ae54c in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 > #2 0xc05ae816 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:572 > #3 0xc05acf63 in _rw_rlock (rw=0xc097830c, file=0xc087092d > "/usr/src/sys/contrib/pf/net/pf.c", line=3016) > at /usr/src/sys/kern/kern_rwlock.c:253 > #4 0xc0473e58 in pf_socket_lookup (direction=2, pd=0xe68463dc, inp_arg=0x0) at > /usr/src/sys/contrib/pf/net/pf.c:3016 > #5 0xc047dd62 in pf_test_tcp (rm=0xe6846444, sm=0xe6846440, direction=2, > kif=0xc3efee00, m=0xc3c8e900, off=40, > h=0xc3c8e944, pd=0xe68463dc, am=0xe6846448, rsm=0xe684643c, ifq=0x0, > inp=0x0) > at /usr/src/sys/contrib/pf/net/pf.c:3270 > #6 0xc04816c0 in pf_test6 (dir=2, ifp=0xc3d44000, m0=0xe68464a0, eh=0x0, > inp=0x0) > at /usr/src/sys/contrib/pf/net/pf.c:7368 > #7 0xc0484e37 in pf_check6_out (arg=0x0, m=0xe68464a0, ifp=0xc3d44000, dir=2, > inp=0x0) > at /usr/src/sys/contrib/pf/net/pf_ioctl.c:3739 > #8 0xc0657618 in pfil_run_hooks (ph=0xc097ad00, mp=0xe6846638, ifp=0xc3d44000, > dir=2, inp=0x0) > at /usr/src/sys/net/pfil.c:78 > #9 0xc07034fe in ip6_output (m0=0xc3c8e900, opt=0x0, ro=0xe6846618, > flags=Variable "flags" is not available. > ) at /usr/src/sys/netinet6/ip6_output.c:853 > #10 0xc0477dad in pf_send_tcp (replyto=0xc4fcfe00, r=0xc41259b4, af=28 '\034', > saddr=0xc4fcfe5c, daddr=0xc4fcfe4c, > sport=20480, dport=46591, seq=0, ack=1170313007, flags=20 '\024', win=0, > mss=0, ttl=0 '\0', tag=1, rtag=0, eh=0x0, > ifp=0xc3f06400) at /usr/src/sys/contrib/pf/net/pf.c:1978 > #11 0xc047e90f in pf_test_tcp (rm=0xe68468e8, sm=0xe68468e4, direction=2, > kif=0xc3f20900, m=0xc4fcfe00, off=40, > h=0xc4fcfe44, pd=0xe6846880, am=0xe68468ec, rsm=0xe68468e0, ifq=0x0, > inp=0xc446b7bc) > at /usr/src/sys/contrib/pf/net/pf.c:3424 > #12 0xc04816c0 in pf_test6 (dir=2, ifp=0xc3f06400, m0=0xe6846944, eh=0x0, > inp=0xc446b7bc) > at /usr/src/sys/contrib/pf/net/pf.c:7368 > #13 0xc0484e37 in pf_check6_out (arg=0x0, m=0xe6846944, ifp=0xc3f06400, dir=2, > inp=0xc446b7bc) > at /usr/src/sys/contrib/pf/net/pf_ioctl.c:3739 > #14 0xc0657618 in pfil_run_hooks (ph=0xc097ad00, mp=0xe6846adc, ifp=0xc3f06400, > dir=2, inp=0xc446b7bc) > at /usr/src/sys/net/pfil.c:78 > #15 0xc07034fe in ip6_output (m0=0xc4fcfe00, opt=0x0, ro=0xe6846abc, > flags=Variable "flags" is not available. > ) at /usr/src/sys/netinet6/ip6_output.c:853 > #16 0xc06debbe in tcp_output (tp=0xc45553a0) at > /usr/src/sys/netinet/tcp_output.c:1114 > #17 0xc06ea5d1 in tcp6_usr_connect (so=0xc50cd340, nam=0xc447e7c0, > td=0xc4eed690) at tcp_offload.h:257 > #18 0xc060b002 in soconnect (so=0xc50cd340, nam=0xc447e7c0, td=0xc4eed690) at > /usr/src/sys/kern/uipc_socket.c:771 > #19 0xc06129e9 in kern_connect (td=0xc4eed690, fd=3, sa=0xc447e7c0) at > /usr/src/sys/kern/uipc_syscalls.c:570 > #20 0xc0612b56 in connect (td=0xc4eed690, uap=0xe6846cfc) at > /usr/src/sys/kern/uipc_syscalls.c:534 > #21 0xc083a2d4 in syscall (frame=0xe6846d38) at > /usr/src/sys/i386/i386/trap.c:1090 > #22 0xc0821220 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 > #23 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > >How-To-Repeat: > > >Fix: > > > > >Release-Note: > >Audit-Trail: > >Unformatted: > _______________________________________________ > freebsd-bugs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-bugs > To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org" From csjp at freebsd.org Wed Sep 17 16:50:08 2008 From: csjp at freebsd.org (Christian Peron) Date: Wed Sep 17 16:50:21 2008 Subject: kern/127439: deadlock in pf Message-ID: <200809171650.m8HGo7F0096278@freefall.freebsd.org> The following reply was made to PR kern/127439; it has been noted by GNATS. From: Christian Peron To: Geoffrey Mainland Cc: Christian Peron , FreeBSD-gnats-submit@freebsd.org Subject: Re: kern/127439: deadlock in pf Date: Wed, 17 Sep 2008 11:47:13 -0500 On Wed, Sep 17, 2008 at 12:21:15PM -0400, Geoffrey Mainland wrote: [..] > > # FTP > pass in on $ext_if inet proto tcp from any to $ext_nat \ > user proxy flags S/SA modulate state > What happens if you get rid of the "user proxy" constraint? We have had problems with these rules in the past. The truth is, they don't really work correctly anyway. But it would be interesting to see if removing the "user proxy" constraint and replacing it with a port or range removes the dead lock. From csjp at freebsd.org Wed Sep 17 17:30:04 2008 From: csjp at freebsd.org (Christian Peron) Date: Wed Sep 17 17:30:10 2008 Subject: kern/127439: deadlock in pf Message-ID: <200809171730.m8HHU4W1098583@freefall.freebsd.org> The following reply was made to PR kern/127439; it has been noted by GNATS. From: Christian Peron To: Christian Peron Cc: Geoffrey Mainland , FreeBSD-gnats-submit@freebsd.org Subject: Re: kern/127439: deadlock in pf Date: Wed, 17 Sep 2008 12:27:43 -0500 Actually -- ignore this request. This is not the problem. On Wed, Sep 17, 2008 at 11:47:13AM -0500, Christian Peron wrote: > On Wed, Sep 17, 2008 at 12:21:15PM -0400, Geoffrey Mainland wrote: > [..] > > > > # FTP > > pass in on $ext_if inet proto tcp from any to $ext_nat \ > > user proxy flags S/SA modulate state > > > > What happens if you get rid of the "user proxy" constraint? We have > had problems with these rules in the past. The truth is, they don't > really work correctly anyway. But it would be interesting to see if > removing the "user proxy" constraint and replacing it with a port or > range removes the dead lock. > From remko at FreeBSD.org Sat Sep 20 20:21:48 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Sat Sep 20 20:21:50 2008 Subject: conf/127511: [patch] /usr/sbin/authpf: add authpf folders to BSD.root.dist and BSD.var.dist mtree files Message-ID: <200809202021.m8KKLmxi060651@freefall.freebsd.org> Old Synopsis: [patch] add authpf folders to BSD.root.dist and BSD.var.dist mtree files New Synopsis: [patch] /usr/sbin/authpf: add authpf folders to BSD.root.dist and BSD.var.dist mtree files Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: remko Responsible-Changed-When: Sat Sep 20 20:21:17 UTC 2008 Responsible-Changed-Why: reassign to Pf team since that's their region. http://www.freebsd.org/cgi/query-pr.cgi?pr=127511 From max at love2party.net Sun Sep 21 22:30:06 2008 From: max at love2party.net (Max Laier) Date: Sun Sep 21 22:30:07 2008 Subject: conf/127511: [patch] /usr/sbin/authpf: add authpf folders to BSD.root.dist and BSD.var.dist mtree files Message-ID: <200809212230.m8LMU5Sw020143@freefall.freebsd.org> The following reply was made to PR conf/127511; it has been noted by GNATS. From: Max Laier To: bug-followup@freebsd.org, ohauer@gmx.de Cc: Subject: Re: conf/127511: [patch] /usr/sbin/authpf: add authpf folders to BSD.root.dist and BSD.var.dist mtree files Date: Mon, 22 Sep 2008 00:07:36 +0200 Leaving this to the administrator was a deliberate choice at the time in order to make sure people who use authpf had read the documentation carefully enough to not shoot themselfs in their feet. I don't have strong feelings about this, however. So if people feel that we should rather provide more rope, I'll commit your patch. Voting time, all in favor say "Aye"? Keep this on freebsd-pf@ though, please. -- Max From ohauer at gmx.de Sun Sep 21 23:10:04 2008 From: ohauer at gmx.de (Olli Hauer) Date: Sun Sep 21 23:10:06 2008 Subject: conf/127511: [patch] /usr/sbin/authpf: add authpf folders to BSD.root.dist and BSD.var.dist mtree files Message-ID: <200809212310.m8LNA4Cv022577@freefall.freebsd.org> The following reply was made to PR conf/127511; it has been noted by GNATS. From: "Olli Hauer" To: Max Laier , bug-followup@freebsd.org Cc: Subject: Re: conf/127511: [patch] /usr/sbin/authpf: add authpf folders to BSD.root.dist and BSD.var.dist mtree files Date: Mon, 22 Sep 2008 00:37:47 +0200 -------- Original-Nachricht -------- > Datum: Mon, 22 Sep 2008 00:07:36 +0200 > Von: Max Laier > An: bug-followup@freebsd.org, ohauer@gmx.de > Betreff: Re: conf/127511: [patch] /usr/sbin/authpf: add authpf folders to BSD.root.dist and BSD.var.dist mtree files > Leaving this to the administrator was a deliberate choice at the time in > order > to make sure people who use authpf had read the documentation carefully > enough > to not shoot themselfs in their feet. I don't have strong feelings about > this, however. So if people feel that we should rather provide more rope, > I'll commit your patch. > > Voting time, all in favor say "Aye"? Keep this on freebsd-pf@ though, > please. > > -- > Max Hm, normaly everyone expect users are reading the man pages or other manuals. Sometime the learning curve will speed up, if you shoot yourself in the food. Something I missed in the patch (see additional diff) --- etc/shells.orig 2000-04-27 23:58:46.000000000 +0200 +++ etc/shells 2008-09-22 00:34:08.000000000 +0200 @@ -7,3 +7,4 @@ /bin/sh /bin/csh /bin/tcsh +/usr/sbin/authpf -- olli -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx From bugmaster at FreeBSD.org Mon Sep 22 11:07:00 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 22 11:07:33 2008 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200809221106.m8MB6x7A015455@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 conf/127511 pf [patch] /usr/sbin/authpf: add authpf folders to BSD.ro o kern/127439 pf [pf] deadlock in pf o 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/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 kern/82271 pf [pf] cbq scheduler cause bad latency 22 problems total. From leslie at eskk.nu Mon Sep 22 11:53:10 2008 From: leslie at eskk.nu (Leslie Jensen) Date: Mon Sep 22 11:53:13 2008 Subject: IMAP server talks back PF blocks Message-ID: <48D7871E.1040902@eskk.nu> When doing tcpdump -n -e -ttt -i pflog0 I frequently see packets blocked that looks like this 458660 rule 0/0(match): block in on em0: xxx.yyy.zzz.qqq.993 > qqq.zzz.yyy.xxx.59930: tcp 8 [bad hdr length 12 - too short, < 20] It's the IMAP server I'm using that tries to talk back. Is this something I should try to let through? /Leslie From leslie at eskk.nu Mon Sep 22 11:53:40 2008 From: leslie at eskk.nu (Leslie Jensen) Date: Mon Sep 22 11:53:42 2008 Subject: Explanation of macro Message-ID: <48D7873C.70903@eskk.nu> I'm setting up a pf firewall and came across this macro SYN_ONLY="S/FSRA" Have tried to find out what it does but have not been successful. Will someone explain Please? Thanks /Leslie From jille at quis.cx Mon Sep 22 12:27:58 2008 From: jille at quis.cx (Jille Timmermans) Date: Mon Sep 22 12:28:25 2008 Subject: Explanation of macro In-Reply-To: <48D7873C.70903@eskk.nu> References: <48D7873C.70903@eskk.nu> Message-ID: <48D78839.2020106@quis.cx> Leslie Jensen wrote: > I'm setting up a pf firewall and came across this macro > > SYN_ONLY="S/FSRA" This means it will only match packets which have only set the SYN flag of FIN, SYN, RST and ACK. This is the case when starting a new (tcp) connection. -- Jille > > Have tried to find out what it does but have not been successful. > > Will someone explain Please? > Thanks > /Leslie > > > > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" From koitsu at FreeBSD.org Mon Sep 22 15:38:07 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 22 15:38:18 2008 Subject: IMAP server talks back PF blocks In-Reply-To: <48D7871E.1040902@eskk.nu> References: <48D7871E.1040902@eskk.nu> Message-ID: <20080922153805.GA29447@icarus.home.lan> On Mon, Sep 22, 2008 at 01:53:02PM +0200, Leslie Jensen wrote: > When doing > tcpdump -n -e -ttt -i pflog0 > > I frequently see packets blocked that looks like this > > 458660 rule 0/0(match): block in on em0: xxx.yyy.zzz.qqq.993 > > qqq.zzz.yyy.xxx.59930: tcp 8 [bad hdr length 12 - too short, < 20] > > It's the IMAP server I'm using that tries to talk back. Is this > something I should try to let through? The blocks are happening, but you're not able to see the full data in the packet due to the snaplen on tcpdump being too small. Add -s 256 to your tcpdump argument and run it again. It looks to me like you have a rule problem; possibly IMAP+SSL isn't being permitted through, so the block ends up happening as a result of an ambiguous "block in on em0" rule you have. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From artemrts at ukr.net Mon Sep 29 08:06:03 2008 From: artemrts at ukr.net (Vitaliy Vladimirovich) Date: Mon Sep 29 08:06:10 2008 Subject: Break connection Message-ID: Hello, guys. I use PF on my FreeBSD firewall and have one question about PF. When user download some big file, such as .AVI, and if speed of downloading is slow, occurs connection breakage. What parametres of global timeouts should be changed what to solve the problem. Thanks! From bugmaster at FreeBSD.org Mon Sep 29 11:06:55 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 29 11:08:22 2008 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200809291106.m8TB6s1D040883@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 conf/127511 pf [patch] /usr/sbin/authpf: add authpf folders to BSD.ro o kern/127439 pf [pf] deadlock in pf o 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/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 kern/82271 pf [pf] cbq scheduler cause bad latency 22 problems total. From max at love2party.net Mon Sep 29 21:56:53 2008 From: max at love2party.net (Max Laier) Date: Mon Sep 29 21:57:00 2008 Subject: Fwd: Please test ipfw and pf uid/gid/jail rules Message-ID: <200809292356.51500.max@love2party.net> Please help testing. It's been confirmed to work for IPFW, let's make sure pf is in good shape, too. Thanks. ---------- Forwarded Message ---------- Subject: Please test ipfw and pf uid/gid/jail rules Date: Monday 29 September 2008 From: Robert Watson To: current@freebsd.org Dear all: Although it didn't show up in 8.x testing to date, it turned out there was a serious stability regression in the ipfw uid/gid/jail rule implementation as a result of moving to rwlocks for inpcbinfo and inpcb. I think I've corrected the sources of the problem in 8.x and 7.x now, but it would be very helpful if people who use ipfw and pf could do some extra testing of these rules with invariants and witness enabled to see if we can't shake out any remaining problems. Thanks, Robert N M Watson Computer Laboratory University of Cambridge ------------------------------------------------------- -- /"\ 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 rwatson at FreeBSD.org Mon Sep 29 22:02:04 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Sep 29 22:02:11 2008 Subject: Fwd: Please test ipfw and pf uid/gid/jail rules In-Reply-To: <200809292356.51500.max@love2party.net> References: <200809292356.51500.max@love2party.net> Message-ID: On Mon, 29 Sep 2008, Max Laier wrote: > Please help testing. It's been confirmed to work for IPFW, let's make sure > pf is in good shape, too. Thanks. A casual glance at pf.c suggests that pf(4) doesn't suffer from the "look up the inpcb even though it's passed down if the socket pointer is NULL" bug that ipfw(4) did, but confirmation that things work properly would definitely be good. Thanks, Robert N M Watson Computer Laboratory University of Cambridge > > ---------- Forwarded Message ---------- > > Subject: Please test ipfw and pf uid/gid/jail rules > Date: Monday 29 September 2008 > From: Robert Watson > To: current@freebsd.org > > > Dear all: > > Although it didn't show up in 8.x testing to date, it turned out there was a > serious stability regression in the ipfw uid/gid/jail rule implementation as a > result of moving to rwlocks for inpcbinfo and inpcb. I think I've corrected > the sources of the problem in 8.x and 7.x now, but it would be very helpful if > people who use ipfw and pf could do some extra testing of these rules with > invariants and witness enabled to see if we can't shake out any remaining > problems. > > Thanks, > > Robert N M Watson > Computer Laboratory > University of Cambridge > ------------------------------------------------------- > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > From max at love2party.net Mon Sep 29 22:08:38 2008 From: max at love2party.net (Max Laier) Date: Mon Sep 29 22:08:45 2008 Subject: Fwd: Please test ipfw and pf uid/gid/jail rules In-Reply-To: References: <200809292356.51500.max@love2party.net> Message-ID: <200809300008.36074.max@love2party.net> On Tuesday 30 September 2008 00:02:04 Robert Watson wrote: > On Mon, 29 Sep 2008, Max Laier wrote: > > Please help testing. It's been confirmed to work for IPFW, let's make > > sure pf is in good shape, too. Thanks. > > A casual glance at pf.c suggests that pf(4) doesn't suffer from the "look > up the inpcb even though it's passed down if the socket pointer is NULL" > bug that ipfw(4) did, but confirmation that things work properly would > definitely be good. http://www.freebsd.org/cgi/query-pr.cgi?pr=127439 looks like it could be related. I think I see what's happening there, but unfortunately I don't have any time to look into it myself at the moment. Might be a while before I get to it so additional eyes are certainly appreciated! > Thanks, > > Robert N M Watson > Computer Laboratory > University of Cambridge > > > ---------- Forwarded Message ---------- > > > > Subject: Please test ipfw and pf uid/gid/jail rules > > Date: Monday 29 September 2008 > > From: Robert Watson > > To: current@freebsd.org > > > > > > Dear all: > > > > Although it didn't show up in 8.x testing to date, it turned out there > > was a serious stability regression in the ipfw uid/gid/jail rule > > implementation as a result of moving to rwlocks for inpcbinfo and inpcb. > > I think I've corrected the sources of the problem in 8.x and 7.x now, but > > it would be very helpful if people who use ipfw and pf could do some > > extra testing of these rules with invariants and witness enabled to see > > if we can't shake out any remaining problems. > > > > Thanks, > > > > Robert N M Watson > > Computer Laboratory > > University of Cambridge > > ------------------------------------------------------- > > -- > > /"\ Best regards, | mlaier@freebsd.org > > \ / Max Laier | ICQ #67774661 > > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > > / \ ASCII Ribbon Campaign | Against HTML Mail and News -- /"\ 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 rwatson at FreeBSD.org Tue Sep 30 06:15:28 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Sep 30 06:15:36 2008 Subject: Fwd: Please test ipfw and pf uid/gid/jail rules In-Reply-To: <200809300008.36074.max@love2party.net> References: <200809292356.51500.max@love2party.net> <200809300008.36074.max@love2party.net> Message-ID: On Tue, 30 Sep 2008, Max Laier wrote: > On Tuesday 30 September 2008 00:02:04 Robert Watson wrote: >> On Mon, 29 Sep 2008, Max Laier wrote: >>> Please help testing. It's been confirmed to work for IPFW, let's make >>> sure pf is in good shape, too. Thanks. >> >> A casual glance at pf.c suggests that pf(4) doesn't suffer from the "look >> up the inpcb even though it's passed down if the socket pointer is NULL" >> bug that ipfw(4) did, but confirmation that things work properly would >> definitely be good. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=127439 looks like it could be > related. I think I see what's happening there, but unfortunately I don't > have any time to look into it myself at the moment. Might be a while before > I get to it so additional eyes are certainly appreciated! There are a number of LOR's in this PR; some are harmless. Here's a quick and casual run-down: 1st 0xc0907fcc pf task mtx (pf task mtx) @ /usr/src/sys/contrib/pf/net/pf_ioctl.c:1394 2nd 0xc0973488 ifnet (ifnet) @ /usr/src/sys/net/if.c:1558 I don't know anything about this. 1st 0xc097830c tcp (tcp) @ /usr/src/sys/netinet/tcp_input.c:400 2nd 0xc09775d8 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:73 This should be fixed by one of my recent TCP changes -- TCP wasn't passing down the inpcb in a situation where it should have been. 1st 0xc4013d44 udpinp (udpinp) @ /usr/src/sys/netinet/udp_usrreq.c:878 2nd 0xc09775d8 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:73 This is the correct order. 1st 0xc423f150 tcpinp (tcpinp) @ /usr/src/sys/netinet/tcp_usrreq.c:472 2nd 0xc09775d8 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:73 This is the correct order. 1st 0xc09786cc udp (udp) @ /usr/src/sys/netinet/udp_usrreq.c:395 2nd 0xc09775d8 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:73 This is the correct order. panic: _rw_rlock (tcp): wlock already held @ /usr/src/sys/contrib/pf/net/pf.c:3016 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c088cf61,e6846220,c05ae7df,c08b659d,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08b659d,0,c0889c7e,e684622c,0,...) at kdb_backtrace+0x29 panic(c0889c7e,c085a754,c088f55e,c087092d,bc8,...) at panic+0x10f _rw_rlock(c097830c,c087092d,bc8,c08d9624,c087092d,...) at _rw_rlock+0x73 pf_socket_lookup(2,e68463dc,0,cc4,3,...) at pf_socket_lookup+0x208 pf_test_tcp(e6846444,e6846440,2,c3efee00,c3c8e900,...) at pf_test_tcp+0x142 pf_test6(2,c3d44000,e68464a0,0,0,...) at pf_test6+0x8a0 pf_check6_out(0,e68464a0,c3d44000,2,0,...) at pf_check6_out+0x47 pfil_run_hooks(c097ad00,e6846638,c3d44000,2,0,...) at pfil_run_hooks+0x88 ip6_output(c3c8e900,0,e6846618,0,0,...) at ip6_output+0x122e pf_send_tcp(c4fcfe00,c41259b4,1c,c4fcfe5c,c4fcfe4c,...) at pf_send_tcp+0x6dd pf_test_tcp(e68468e8,e68468e4,2,c3f20900,c4fcfe00,...) at pf_test_tcp+0xcef pf_test6(2,c3f06400,e6846944,0,c446b7bc,...) at pf_test6+0x8a0 pf_check6_out(0,e6846944,c3f06400,2,c446b7bc,...) at pf_check6_out+0x47 pfil_run_hooks(c097ad00,e6846adc,c3f06400,2,c446b7bc,...) at pfil_run_hooks+0x88 ip6_output(c4fcfe00,0,e6846abc,0,0,...) at ip6_output+0x122e tcp_output(c45553a0,c447e7c0,201,c446b858,c45553a0,...) at tcp_output+0x137e tcp6_usr_connect(c50cd340,c447e7c0,c4eed690,25,e6846c64,...) at tcp6_usr_connect+0x171 soconnect(c50cd340,c447e7c0,c4eed690,1c,16,...) at soconnect+0x52 kern_connect(c4eed690,3,c447e7c0,c447e7c0,0,...) at kern_connect+0x59 connect(c4eed690,e6846cfc,c,c08a288e,c08d3a50,...) at connect+0x46 syscall(e6846d38) at syscall+0x274 This looks like a recursion bug in pf(4) -- you can't look up sockets in that output context because youre already running in a context where connection locks are held. If it's for the same TCP connection, you need to pass down the inpcb into ip6_output(), but if it's for a different one, you ned to run the output code in a deferred context so that it can recurse safely back into the inpcb code. Robert N M Watson Computer Laboratory University of Cambridge > >> Thanks, >> >> Robert N M Watson >> Computer Laboratory >> University of Cambridge >> >>> ---------- Forwarded Message ---------- >>> >>> Subject: Please test ipfw and pf uid/gid/jail rules >>> Date: Monday 29 September 2008 >>> From: Robert Watson >>> To: current@freebsd.org >>> >>> >>> Dear all: >>> >>> Although it didn't show up in 8.x testing to date, it turned out there >>> was a serious stability regression in the ipfw uid/gid/jail rule >>> implementation as a result of moving to rwlocks for inpcbinfo and inpcb. >>> I think I've corrected the sources of the problem in 8.x and 7.x now, but >>> it would be very helpful if people who use ipfw and pf could do some >>> extra testing of these rules with invariants and witness enabled to see >>> if we can't shake out any remaining problems. >>> >>> Thanks, >>> >>> Robert N M Watson >>> Computer Laboratory >>> University of Cambridge >>> ------------------------------------------------------- >>> -- >>> /"\ Best regards, | mlaier@freebsd.org >>> \ / Max Laier | ICQ #67774661 >>> X http://pf4freebsd.love2party.net/ | mlaier@EFnet >>> / \ ASCII Ribbon Campaign | Against HTML Mail and News > > -- > /"\ 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 tomh at huppi.com Tue Sep 30 08:12:15 2008 From: tomh at huppi.com (Tom Huppi) Date: Tue Sep 30 08:12:21 2008 Subject: Need best practice advice: carp and /30 Message-ID: <20080930074533.GA7549@huppi.com> I am trying to build a pfsync implementation so that I can work on various hardening and other experiments with minimal downtime, and could use some advice. I expect to be using the most current FreeBSD codebase with this implementation. Indeed, being able to do so is a driving force behind my project. My network layout looks like so: ----------------- /-- | em0 PF-1 em1 | --- | ------------ | / | em2 | ISP -- | special vlan | ---------------- | cisco 3560 | | |------------- |\ ---------------- \ | em2 | - | em0 PF-2 em1 | ---- ---------------- My ISP provides a single IP on a /30. Say 70.187.255.246, and that carries my class-C traffic which is on a different subnet entirely. A similar solution but with only one PF firewall (also acting as a simple router) has been working well enough over the last 10 months, although I did have certain problems which I have yet to get to the bottom of. Possibly they have something to do with the Cisco which I neglected to mention in my last query to this list since I thought it unimportant at the time. Anyway, my question relates to what are best-practices vis-a-vis the network of the 'em0' interface. Pretty clearly the carp0 interface is my ISP assigned one, but there is not room in the /30 for other addresses. My guess is that I should 'invent' a RFC1918 network for the two em0 interfaces, but I certainly don't want this to cause wierd problems in the VLAN (I don't anticipate doing any routing in this VLAN, by the way.) In my googleing I found some info about getting 'carpdev' supported and the threads seem to have dried up over a year ago, so I think that it is probably in and working these days(?) Even if so, still remains unclear to me what is safe and appropriate in my situation. If anyone has experiance with a similar setup and hardware, I would very much appreciate knowing of their experiances. The IOS revision on the Cisco is from about a year ago...don't have it handy, but can get it if it is a factor. (Also, thank you to all who had input on my last question to the list. I got some feedback from my ISP about it, but it only adds to the mystery. I'll follow-up on that thread when I know more.) Thanks, - Tom -- From catalin at starcomms.com Tue Sep 30 14:50:02 2008 From: catalin at starcomms.com (Catalin Miclaus) Date: Tue Sep 30 14:50:09 2008 Subject: Need best practice advice: carp and /30 In-Reply-To: <20080930074533.GA7549@huppi.com> References: <20080930074533.GA7549@huppi.com> Message-ID: <3A0AA7018522134597ED63B3B794C92A0301B363@STA-HQ-S001.starcomms.local> -----Original Message----- From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-pf@freebsd.org] On Behalf Of Tom Huppi Sent: Tuesday, September 30, 2008 8:46 AM To: freebsd-pf@freebsd.org Subject: Need best practice advice: carp and /30 I am trying to build a pfsync implementation so that I can work on various hardening and other experiments with minimal downtime, and could use some advice. I expect to be using the most current FreeBSD codebase with this implementation. Indeed, being able to do so is a driving force behind my project. My network layout looks like so: ----------------- /-- | em0 PF-1 em1 | --- | ------------ | / | em2 | ISP -- | special vlan | ---------------- | cisco 3560 | | |------------- |\ ---------------- \ | em2 | - | em0 PF-2 em1 | ---- ---------------- My ISP provides a single IP on a /30. Say 70.187.255.246, and that carries my class-C traffic which is on a different subnet entirely. A similar solution but with only one PF firewall (also acting as a simple router) has been working well enough over the last 10 months, although I did have certain problems which I have yet to get to the bottom of. Possibly they have something to do with the Cisco which I neglected to mention in my last query to this list since I thought it unimportant at the time. Anyway, my question relates to what are best-practices vis-a-vis the network of the 'em0' interface. Pretty clearly the carp0 interface is my ISP assigned one, but there is not room in the /30 for other addresses. My guess is that I should 'invent' a RFC1918 network for the two em0 interfaces, but I certainly don't want this to cause wierd problems in the VLAN (I don't anticipate doing any routing in this VLAN, by the way.) In my googleing I found some info about getting 'carpdev' supported and the threads seem to have dried up over a year ago, so I think that it is probably in and working these days(?) Even if so, still remains unclear to me what is safe and appropriate in my situation. If anyone has experiance with a similar setup and hardware, I would very much appreciate knowing of their experiances. The IOS revision on the Cisco is from about a year ago...don't have it handy, but can get it if it is a factor. (Also, thank you to all who had input on my last question to the list. I got some feedback from my ISP about it, but it only adds to the mystery. I'll follow-up on that thread when I know more.) Thanks, - Tom On external interface you need to configure at least the default route. Moreover your ISP will have to configure same private range on his equipments which I doubt he will agree. The way I see it you have 2 solutions: 1. request for a /29 from your ISP 2. use enhanced image for 3560 (that will make it a layer 3 device) with private range to your firewalls and public range on the ISP link Best Regards Catalin Miclaus ISP-Data Ops. Starcomms Ltd. -- _______________________________________________ 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" DISCLAIMER: The information contained in this message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and permanently delete this message and any attachments from your system. Any form of dissemination, use, review, distribution, printing or copying of this message in whole or in part is strictly prohibited if you are not the intended recipient of this e-mail. Please note that e-mails are susceptible to change. STARCOMMS PLC shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. STARCOMMS PLC does not guarantee that the integrity of this communication has been maintained or that this communication is free of viruses, interceptions or interferences. STARCOMMS PLC reserves the right to monitor all e-mail communications, whether related to the business of STARCOMMS or not, through its internal or external networks. From tomh at huppi.com Tue Sep 30 21:12:34 2008 From: tomh at huppi.com (Tom Huppi) Date: Tue Sep 30 21:12:40 2008 Subject: Need best practice advice: carp and /30 In-Reply-To: <3A0AA7018522134597ED63B3B794C92A0301B363@STA-HQ-S001.starcomms.local> References: <20080930074533.GA7549@huppi.com> <3A0AA7018522134597ED63B3B794C92A0301B363@STA-HQ-S001.starcomms.local> Message-ID: <20080930211232.GA35980@huppi.com> On 10:44 Tue 30 Sep , Catalin Miclaus wrote: > tomh writes: > > I am trying to build a pfsync implementation so that I can > > work on various hardening and other experiments with minimal > > downtime, and could use some advice. > > > > I expect to be using the most current FreeBSD codebase with this > > implementation. Indeed, being able to do so is a driving force > > behind my project. > > > > My network layout looks like so: > > > > > > > > ----------------- > > /-- | em0 PF-1 em1 | --- > > | ------------ | / | em2 | > > ISP -- | special vlan | ---------------- > > | cisco 3560 | | > > |------------- |\ ---------------- > > \ | em2 | > > - | em0 PF-2 em1 | ---- > > ---------------- > > > > > > > > My ISP provides a single IP on a /30. Say 70.187.255.246, and > > that carries my class-C traffic which is on a different subnet > > entirely. > > > > A similar solution but with only one PF firewall (also acting as > > a simple router) has been working well enough over the last 10 > > months, although I did have certain problems which I have yet to > > get to the bottom of. Possibly they have something to do with > > the Cisco which I neglected to mention in my last query to this > > list since I thought it unimportant at the time. > > > > Anyway, my question relates to what are best-practices vis-a-vis > > the network of the 'em0' interface. Pretty clearly the carp0 > > interface is my ISP assigned one, but there is not room in the > > /30 for other addresses. > > > > My guess is that I should 'invent' a RFC1918 network for the two > > em0 interfaces, but I certainly don't want this to cause wierd > > problems in the VLAN (I don't anticipate doing any routing in > > this VLAN, by the way.) > > > > In my googleing I found some info about getting 'carpdev' > > supported and the threads seem to have dried up over a year > > ago, so I think that it is probably in and working these days(?) > > Even if so, still remains unclear to me what is safe and > > appropriate in my situation. > > > > If anyone has experiance with a similar setup and hardware, I > > would very much appreciate knowing of their experiances. The > > IOS revision on the Cisco is from about a year ago...don't have > > it handy, but can get it if it is a factor. > > > > (Also, thank you to all who had input on my last question to the > > list. I got some feedback from my ISP about it, but it only > > adds to the mystery. I'll follow-up on that thread when I know > > more.) > > > > Thanks, > > > > - Tom > > > On external interface you need to configure at least the default route. > Moreover your ISP will have to configure same private range on his > equipments which I doubt he will agree. > > The way I see it you have 2 solutions: > > 1. request for a /29 from your ISP > 2. use enhanced image for 3560 (that will make it a layer 3 device) with > private range to your firewalls and public range on the ISP link Thank you for your suggestions. The 3560 I have to work with has 'C3560-IPBASE-M' while the one I have currently in production has 'C3560-ADVIPSERVICESK9-M'. I think that both of these IOS version would do simple VLAN routing. I am very much a novice at this and don't use any VLAN routing at all currently since I was able to do the simple stuff I needed host-side in on my current setup. (I have been planning to abandon that strategy with my new carp implementation and try to do more with VLAN routing, but that is on the 'other side' of the issue I am currently trying to deal with.) I wonder if it would/could work to have something like: ---------- ---------- ISP --> | 3560 | --> | 3560 | -- em0:pf-1 | VLAN /30 | | VLAN /29 | -- em0:pf-2 ---------- ---------- where I arrange appropriate routing between the two VLANs? Perhaps that is basically what you are suggesting? I am quite confused about what traffic one would expect to see makeing it out of the em0 interfaces when carp is active and working. Relatedly, what exactly the default route does in such a scenerio. These details don't seem to be broadly described in the documentation I have run across so far. Thanks again for any thoughts on the matter. - Tom > Best Regards > Catalin Miclaus > ISP-Data Ops. > Starcomms Ltd. > > > > -- > _______________________________________________ > 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" > > > DISCLAIMER: The information contained in this message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and permanently delete this message and any attachments from your system. Any form of dissemination, use, review, distribution, printing or copying of this message in whole or in part is strictly prohibited if you are not the intended recipient of this e-mail. Please note that e-mails are susceptible to change. STARCOMMS PLC shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. STARCOMMS PLC does not guarantee that the integrity of this communication has been maintained or that this communication is free of viruses, interceptions or interferences. STARCOMMS PLC reserves the right to monitor all e-mail communications, whether related to the business of STARCOMMS or not, through its internal or external networks. --