Re: Future of pf / firewall in FreeBSD ? - does it have one ?
I always found natting in ipfw rather awkward and harder than in pf. Looking at the man page it doesnt seem to have changed. I should probably give it another go though as it has been about 10 years now On 31 July 2014 14:41, Gleb Smirnoff gleb...@freebsd.org wrote: On Thu, Jul 31, 2014 at 10:02:22PM +1000, Da Rock wrote: D Without diminishing your efforts so far, what do you think about D pitching all efforts into IPFW to combine effort and reduce overhead of D maintaining separate firewalls in the core? Is there an advantage to D having our own pf? Is there any disadvantage keeping it? It is a plugin. It is optional and loadable. I removed most additions to the network stack that live outside netpfil/pf. Some people like it and use it. It is also the only tool to configure ALTQ now. -- Totus tuus, Glebius. ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
------ From:kradkra...@gmail.com; Date:2014??8??1??(??) 3:39 To:Gleb Smirnoffgleb...@freebsd.org; Cc:freebsd-currentfreebsd-current@freebsd.org;FreeBSD Questionsfreebsd-questi...@freebsd.org; Subject:Re: Future of pf / firewall in FreeBSD ? - does it have one ? I always found natting in ipfw rather awkward and harder than in pf. Looking at the man page it doesnt seem to have changed. I should probably give it another go though as it has been about 10 years now On 31 July 2014 14:41, Gleb Smirnoff gleb...@freebsd.org wrote: On Thu, Jul 31, 2014 at 10:02:22PM +1000, Da Rock wrote: D Without diminishing your efforts so far, what do you think about D pitching all efforts into IPFW to combine effort and reduce overhead of D maintaining separate firewalls in the core? Is there an advantage to D having our own pf? Is there any disadvantage keeping it? It is a plugin. It is optional and loadable. I removed most additions to the network stack that live outside netpfil/pf. Some people like it and use it. It is also the only tool to configure ALTQ now. -- Totus tuus, Glebius. ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
------ From:kradkra...@gmail.com; Date:2014??8??1??(??) 3:39 To:Gleb Smirnoffgleb...@freebsd.org; Cc:freebsd-currentfreebsd-current@freebsd.org;FreeBSD Questionsfreebsd-questi...@freebsd.org; Subject:Re: Future of pf / firewall in FreeBSD ? - does it have one ? I always found natting in ipfw rather awkward and harder than in pf. Looking at the man page it doesnt seem to have changed. I should probably give it another go though as it has been about 10 years now On 31 July 2014 14:41, Gleb Smirnoff gleb...@freebsd.org wrote: On Thu, Jul 31, 2014 at 10:02:22PM +1000, Da Rock wrote: D Without diminishing your efforts so far, what do you think about D pitching all efforts into IPFW to combine effort and reduce overhead of D maintaining separate firewalls in the core? Is there an advantage to D having our own pf? Is there any disadvantage keeping it? It is a plugin. It is optional and loadable. I removed most additions to the network stack that live outside netpfil/pf. Some people like it and use it. It is also the only tool to configure ALTQ now. -- Totus tuus, Glebius. ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
July 31 2014 2:41 AM, Darren Pilgrim wrote: No. I believe pf should be removed from FreeBSD and efforts refocused on keeping ipfw up to date and feature complete. It makes more sense to look at what pf, ipf, nbtables, etc. are all doing as a source of ideas for what we can do with ipfw. A decade ago, there was justification for adding pf: at the time, ipfw lacked some major features. Ipfw has since caught up. I see no remaining value in having more than one packet filter in the base. Ipfw is more mature and less broken, so we should keep it and ditch the rest in the name of survival efficiency. pf is not simply replaceable in many environments. For example, people use it specifically for its integration with the spamd greylisting daemon. I think it's reasonable to assume they did so because the whole spam filtering stack performs better on FreeBSD than on OpenBSD. This was just recently mentioned on twitter: @ng_security Why was the pf ioctl needed buffer reduced in FreeBSD 10? I'm not able to load my full spamd blacklist anymore. @freebsd #spamd #pf https://twitter.com/ng_security/status/494982307905040384 I personally use pf for many reasons, spamd included. I don't think anyone out there is interested in forking spamd to play ball with ipfw so we would also be alienating these users who can't just change packet filters. Is there even an equivalent to pfsync for ipfw? I didn't think so, but I could be wrong... In the world of firewalls pf has been put on a quite a pedestal. OpenBSD pushed it hard and it marketed it well; people found it both powerful and easy to use which created a cult following and lots of word of mouth advertising. I find it hard to agree with removing pf from FreeBSD because of the existing userbase. If there was an experimental label on it I would find its removal easier to swallow. I think it's worth pointing out that nobody really wanted to maintain an incompatible fork of ZFS indefinitely either; it would be a monumental if not suicidal task. And who wants to deal with the bad PR about FreeBSD being years behind Illumos features or, *gasp*, even letting a native Linux implementation one-up us? People found a way to collaborate, OpenZFS movement was founded, and this is a mostly solved problem, OS nuances aside. I can appreciate that people seem to care more about their data than their packet filters and FreeBSD ZFS certainly moves a lot of servers and appliances furthering the userbase whether or not they're using FreeBSD or TrueOS or some other derivative. Let's continue to give people another reason to put FreeBSD in their datacenters. Let's try to compete in the firewall/packet filter space too. On a side note I'd also like to point out that FreeBSD has been advertising pf by listing it first in the handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls.html I'm sure there's a subliminal message being sent there, intentional or not. I don't want to see FreeBSD lose mindshare from its absence in a time where FreeBSD uptake seems to be rising thanks in part to bad decisions in the GNU/Linux camp. This feels like a solvable problem if funding and enthusiasm is put behind it. OpenBSD really sounds willing to collaborate if not just because they're tired of seeing neglected forks of one of their prized babies: FreeBSD, NetBSD, DragonFlyBSD, OSX, iOS... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
In freebsd-questions Digest, Vol 530, Issue 5, Message: 1 On Thu, 31 Jul 2014 22:02:22 +1000 Da Rock freebsd-questi...@herveybayaustralia.com.au wrote: On 07/29/14 20:35, Gleb Smirnoff wrote: On Sun, Jul 20, 2014 at 12:30:59PM -0400, Mike. wrote: M | imho, the root problem here is that an effort to implement a M single M | feature improvement (multi-threading) has caused the FreeBSD M version M | of pf to apparently reach a near-unmaintainable position in the M | FreeBSD community because improvements from OpenBSD can no longer M be M | ported over easily. FreeBSD's pf has been put in a virtual M | isolation chamber due to the multi-threaded enhancement. M | M | Was it worth it? M | M |Yes. This happened *three times* in BSD land now. How much more M |proof does it take to make that clear? M |[snip] M M In this instance, more proof would consist of pf development not M wallowing in inactivity. M M imo, tactical changes were implemented in pf without the strategic M negative consequences affecting the decision process guiding the M implementation of those tactical features.And that's backwards. M Strategies direct tactics, not vice versa. I would strongly disagree with you. I would claim that directions I've put in pf in 2012 are strategically correct, while previous life of pf in FreeBSD was not. History: pf appeared in FreeBSD in 2004 in 5.3-RELEASE. It was already outdated. It isn't possible otherwise. While Max spent time on porting some stable version, the OpenBSD moved forward. It was later updated again by Max, and again right after update it was outdated. I mean that people who a) believe that OpenBSD pf is the one true b) eager for bleeding edge version, these people simply cannot be satisfied. A porter needs to take latest stable version from OpenBSD and spend some time working on it. So, pf in FreeBSD was always outdated, even before my SMP work on it. Further history: in 2012 Ermal updates pf and 9.0-RELEASE is shipped. In 2004 we've got 10 years of diverging developement between FreeBSD and OpenBSD. In 2012 it was 18 years. Porting got harder. The pf in 9.x is again outdated and introduces a number of bugs that were not present in 8.x (regressions). Most regressions didn't came from OpenBSD, but were artifacts of porting. Also, the number of #ifdefs in code became so unbearable that no one would want to go through code fixing bugs. In 2012 for me it was obvious that following this route is strategically incorrect. You are never up to date. You need more efforts to port pf, and you yield in a port of worse and worse quality over time. So, in 2012 I put a lot of efforts to not only bring pf out of a single mutex, but also make it more native to FreeBSD. You can read this through commit logs. The net result is that we got our own pf, that can be maintained further. Unfortunately, still no person is seen on horizon who can take maintainership. That explains it rather well. Thank you for the enlightenment on this. Indeed. This potted history covers a lot of ground, and work, to most of which I've been largely oblivious. I've used ipfw since '98; it well suited my assembler background and perhaps overly orthogonal tendencies, and I found dummynet hugely useful for herding small networks of unruly cats, so I've felt no need to explore pf, nor ipfilter. Without diminishing your efforts so far, what do you think about pitching all efforts into IPFW to combine effort and reduce overhead of maintaining separate firewalls in the core? Is there an advantage to having our own pf? Quoting Gleb's response from a later message: Is there any disadvantage keeping it? It is a plugin. It is optional and loadable. I removed most additions to the network stack that live outside netpfil/pf. Some people like it and use it. It is also the only tool to configure ALTQ now. I think each of those is sufficient reason for existence, as long as there's ongoing people - at least a few - who care enough about it. Maybe it needs to become 'fpf' and be happy to complete its forking? I can't imagine pf or ipfilter people deciding to work on ipfw. For one thing, ipfw has quite a few people working on aspects, development is conservatively ongoing, with no discernable shortage of volunteers. For another, I feel that there are distinct philosophical differences at the level of rule definition languages. From my little reading, pf uses more high-level symbolic language, where ipfw is relentlessly linear and closer to bare metal. Different people will be attracted to, and will be able to work most efficiently with, such different approaches. I've no idea how pf works at the kernel level, as compared with ipfw's virtual machine opcode execution; I daresay each has its strengths and weaknesses.
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Aug 1, 2014, at 8:46, Mark Felder f...@freebsd.org wrote: I personally use pf for many reasons, spamd included. I don't think anyone out there is interested in forking spamd to play ball with ipfw so we would also be alienating these users who can't just change packet filters. Is there even an equivalent to pfsync for ipfw? I didn't think so, but I could be wrong... In the world of firewalls pf has been put on a quite a pedestal. OpenBSD pushed it hard and it marketed it well; people found it both powerful and easy to use which created a cult following and lots of word of mouth advertising. I find it hard to agree with removing pf from FreeBSD because of the existing userbase. If there was an experimental label on it I would find its removal easier to swallow. I have remained silent on this for two reasons: 1. I am a consumer of FreeBSD. I am a sysadmin, I am NOT a coder and *I* would not want any code that *I* wrote in the kernel of an OS that I was running. I know my limitations. So I could not contribute to the development of pf in FreeBSD 2. Where I use packet filters on a host, and that is not very much, I tend to use ipfilter because in those case my needs are simple. For heavy duty (read: gateway) filtering I use commercial firewalls like the Checkpoint 600 series. So the inclusion or exclusion of pf has no direct effect on me. Having said all that, the reason I use FreeBSD over other open source OSes right now is that it is, in my opinion, the most “grown up” option. I have never seen Linux as an Enterprise tier OS due to a number of basic design decisions made by Linus and those around him. Illumos is very good, but fairly narrow in both it’s hardware support and feature set. I never took a long hard look at the other BSDs as FreeBSD was recommended by a friend and I liked what I found, ESPECIALLY the documentation in the Handbook. I have read a lot of arguments on both sides of the pf in FreeBSD debate over the past weeks. Realistically I think what it comes down to is whether there is someone, a person, an individual with the necessary skill set and drive and desire (and that can be motivated by funding) to take ownership of it and run with it. If there is not, then I think pf in FreeBSD dies. No matter how many people want it to continue, no matter if it is best for FreeBSD for it to continue. Without someone to take ownership of it, then even if it continues it will not be top quality, and having something in FreeBSD that is not top quality would be a mistake (IMHO). -- Paul Kraus p...@kraus-haus.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Cy Schubert wrote this message on Wed, Jul 23, 2014 at 09:18 -0700: In message CAJ-Vmo=_vLkMZn02EPUmpvqugcT8ga1_Kqs=XU49SGUNGEO0Pw@mail.gmail.c om , Adrian Chadd writes: On 18 July 2014 07:34, krad kra...@gmail.com wrote: that is true and I have not problem using man pages, however thats not the way most of the world work and search engines arent exactly new either. We should be trying to engage more people not less, and part of that is reaching out. Then do the port and maintain it. The problem isn't the desire to keep things up to date, it's a lack of people who want that _and_ are willing/able to do it _and_ are funded somehow. Funding is the issue. Sure, some of us maintain software because a personal need however without funding one has to fit maintaining software into whatever time is left. For those of us who do this without funding you manage to squeeze in an hour here or there. Then write a proposal and submit it to the Foundation.. If you don't ask for funding, it rarely shows up... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 8/1/14, 3:39 PM, krad wrote: I always found natting in ipfw rather awkward and harder than in pf. Looking at the man page it doesnt seem to have changed. I should probably give it another go though as it has been about 10 years now since ipfw now has a 'nat' keyword you might say that is has changed in that 10 years. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 7/29/2014 3:18 AM, Gleb Smirnoff wrote: Darren, On Sat, Jul 19, 2014 at 09:36:06PM -0700, Darren Pilgrim wrote: D Never mistake silence for consent. D D The vast majority of people don't know pf is outdated and broken on D FreeBSD because they don't know what they're missing and likely aren't D using IPv6 yet. The moment you turn on IPv6 and restart a validating D unbound, you run full-speed into pf's broken behaviour. Make an D EDNS0-enabled query for a signed zone and you'll get a fragmented UDP D packet that will never make it through unless you tell pf to allow all D fragments unconditionally. They'll simply think something is wrong with D unbound, turn off EDNS0 and/or validation, hurt peformance and/or D security in the process, and never realize their firewall is doing D literally the worst possible thing it could do. D D All because over half a decade ago some folks got all butthurt over a D config file format change. Do I understand you right, that you propose a tens thousands lines of untrivial code bulk update in order to fix a particular bug, that can be nailed down separately? No. I believe pf should be removed from FreeBSD and efforts refocused on keeping ipfw up to date and feature complete. It makes more sense to look at what pf, ipf, nbtables, etc. are all doing as a source of ideas for what we can do with ipfw. A decade ago, there was justification for adding pf: at the time, ipfw lacked some major features. Ipfw has since caught up. I see no remaining value in having more than one packet filter in the base. Ipfw is more mature and less broken, so we should keep it and ditch the rest in the name of survival efficiency. Do you also say that breaking configuration files for a large number of people is okay if the update is expected to fix a bug unrelated to configuration? Yes. Loss of configuration file backward compatibility is a fact of progress. Here are some examples of places where FreeBSD broke backward compatibility of a configuration file: - rc.conf (with every major version change) - resolv.conf - kernels - make.conf vs. src.conf - the ports collection - pkg vs. pkgng - pkgng changes within pkgng 1.x On top of that, we also have whole chunks of the OS where compatibility was broken (e.g., the toolchain, switch to unbound, etc.). For me sounds like hunting a sparrow with a cannon. The whole thing, to me, was an example of lobbyist politics: a vocal minority had the resources and access to stop progress. Now we are all suffering for their ignorance and arrogance. If anything, we should rename pf to tppf (short for Tea Party Packet Filter). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 30/07/2014 2:54 AM, Kevin Oberman wrote: ... I would hope that is not the case. While NAT66 is well known and has been a topic of discussion for years, NPT66 is relatively new. It does share many concepts with NAT66 (and, most likely implementations also share code), but does not require any state, making it vastly less complex and no longer breaks point to point networking. The names look similar, which may result in unfortunate confusion, but NPT66 may be the bast solution to a real problem and it does not create the issues of NAT66. NPT66 is a subset of NAT66. Cheers, Darren ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 07/29/14 20:35, Gleb Smirnoff wrote: On Sun, Jul 20, 2014 at 12:30:59PM -0400, Mike. wrote: M | imho, the root problem here is that an effort to implement a M single M | feature improvement (multi-threading) has caused the FreeBSD M version M | of pf to apparently reach a near-unmaintainable position in the M | FreeBSD community because improvements from OpenBSD can no longer M be M | ported over easily. FreeBSD's pf has been put in a virtual M | isolation chamber due to the multi-threaded enhancement. M | M | Was it worth it? M | M |Yes. This happened *three times* in BSD land now. How much more M |proof does it take to make that clear? M |[snip] M M In this instance, more proof would consist of pf development not M wallowing in inactivity. M M imo, tactical changes were implemented in pf without the strategic M negative consequences affecting the decision process guiding the M implementation of those tactical features.And that's backwards. M Strategies direct tactics, not vice versa. I would strongly disagree with you. I would claim that directions I've put in pf in 2012 are strategically correct, while previous life of pf in FreeBSD was not. History: pf appeared in FreeBSD in 2004 in 5.3-RELEASE. It was already outdated. It isn't possible otherwise. While Max spent time on porting some stable version, the OpenBSD moved forward. It was later updated again by Max, and again right after update it was outdated. I mean that people who a) believe that OpenBSD pf is the one true b) eager for bleeding edge version, these people simply cannot be satisfied. A porter needs to take latest stable version from OpenBSD and spend some time working on it. So, pf in FreeBSD was always outdated, even before my SMP work on it. Further history: in 2012 Ermal updates pf and 9.0-RELEASE is shipped. In 2004 we've got 10 years of diverging developement between FreeBSD and OpenBSD. In 2012 it was 18 years. Porting got harder. The pf in 9.x is again outdated and introduces a number of bugs that were not present in 8.x (regressions). Most regressions didn't came from OpenBSD, but were artifacts of porting. Also, the number of #ifdefs in code became so unbearable that no one would want to go through code fixing bugs. In 2012 for me it was obvious that following this route is strategically incorrect. You are never up to date. You need more efforts to port pf, and you yield in a port of worse and worse quality over time. So, in 2012 I put a lot of efforts to not only bring pf out of a single mutex, but also make it more native to FreeBSD. You can read this through commit logs. The net result is that we got our own pf, that can be maintained further. Unfortunately, still no person is seen on horizon who can take maintainership. That explains it rather well. Thank you for the enlightenment on this. Without diminishing your efforts so far, what do you think about pitching all efforts into IPFW to combine effort and reduce overhead of maintaining separate firewalls in the core? Is there an advantage to having our own pf? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Thu, Jul 31, 2014 at 10:02:22PM +1000, Da Rock wrote: D Without diminishing your efforts so far, what do you think about D pitching all efforts into IPFW to combine effort and reduce overhead of D maintaining separate firewalls in the core? Is there an advantage to D having our own pf? Is there any disadvantage keeping it? It is a plugin. It is optional and loadable. I removed most additions to the network stack that live outside netpfil/pf. Some people like it and use it. It is also the only tool to configure ALTQ now. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 2014-07-29 0:07, Kevin Oberman wrote: And all IPv6 NAT is evil and should be cast into (demonic residence of your choosing) on sight! NAT on IPv6 serves no useful purpose at all. It only serves to complicate things and make clueless security officers happy. It adds zero security. It is a great example of people who assume that NAT is a security feature in IPv4 (it's not) so it should also be in IPv6. .. So putting support for NAT66 or any IPv6 NAT into a firewall is just making things worse. Please don't do it! Well said I'm actually rather relieved that natd can/should go away. Stops giving me migraines with all those special protocl cases that don't like to be natted.. Which of course started as early as FTP. --WjW ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 29/07/2014 8:07 AM, Kevin Oberman wrote: ... And all IPv6 NAT is evil and should be cast into (demonic residence of your choosing) on sight! For the most part, I agree with you but the problem is checkbox comparisons. That IPv6 shouldn't be NAT'd is why I didn't implement it for such a long time. However given the problem that EIDs pose for privacy, I'm of the opinion that maybe NAT66 does have a place but not in the way that the NAT66 RFC prescribes. Darren ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Darren, On Sat, Jul 19, 2014 at 09:36:06PM -0700, Darren Pilgrim wrote: D Never mistake silence for consent. D D The vast majority of people don't know pf is outdated and broken on D FreeBSD because they don't know what they're missing and likely aren't D using IPv6 yet. The moment you turn on IPv6 and restart a validating D unbound, you run full-speed into pf's broken behaviour. Make an D EDNS0-enabled query for a signed zone and you'll get a fragmented UDP D packet that will never make it through unless you tell pf to allow all D fragments unconditionally. They'll simply think something is wrong with D unbound, turn off EDNS0 and/or validation, hurt peformance and/or D security in the process, and never realize their firewall is doing D literally the worst possible thing it could do. D D All because over half a decade ago some folks got all butthurt over a D config file format change. Do I understand you right, that you propose a tens thousands lines of untrivial code bulk update in order to fix a particular bug, that can be nailed down separately? Do you also say that breaking configuration files for a large number of people is okay if the update is expected to fix a bug unrelated to configuration? For me sounds like hunting a sparrow with a cannon. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Sun, Jul 20, 2014 at 12:30:59PM -0400, Mike. wrote: M | imho, the root problem here is that an effort to implement a M single M | feature improvement (multi-threading) has caused the FreeBSD M version M | of pf to apparently reach a near-unmaintainable position in the M | FreeBSD community because improvements from OpenBSD can no longer M be M | ported over easily. FreeBSD's pf has been put in a virtual M | isolation chamber due to the multi-threaded enhancement. M | M | Was it worth it? M | M |Yes. This happened *three times* in BSD land now. How much more M |proof does it take to make that clear? M |[snip] M M In this instance, more proof would consist of pf development not M wallowing in inactivity. M M imo, tactical changes were implemented in pf without the strategic M negative consequences affecting the decision process guiding the M implementation of those tactical features.And that's backwards. M Strategies direct tactics, not vice versa. I would strongly disagree with you. I would claim that directions I've put in pf in 2012 are strategically correct, while previous life of pf in FreeBSD was not. History: pf appeared in FreeBSD in 2004 in 5.3-RELEASE. It was already outdated. It isn't possible otherwise. While Max spent time on porting some stable version, the OpenBSD moved forward. It was later updated again by Max, and again right after update it was outdated. I mean that people who a) believe that OpenBSD pf is the one true b) eager for bleeding edge version, these people simply cannot be satisfied. A porter needs to take latest stable version from OpenBSD and spend some time working on it. So, pf in FreeBSD was always outdated, even before my SMP work on it. Further history: in 2012 Ermal updates pf and 9.0-RELEASE is shipped. In 2004 we've got 10 years of diverging developement between FreeBSD and OpenBSD. In 2012 it was 18 years. Porting got harder. The pf in 9.x is again outdated and introduces a number of bugs that were not present in 8.x (regressions). Most regressions didn't came from OpenBSD, but were artifacts of porting. Also, the number of #ifdefs in code became so unbearable that no one would want to go through code fixing bugs. In 2012 for me it was obvious that following this route is strategically incorrect. You are never up to date. You need more efforts to port pf, and you yield in a port of worse and worse quality over time. So, in 2012 I put a lot of efforts to not only bring pf out of a single mutex, but also make it more native to FreeBSD. You can read this through commit logs. The net result is that we got our own pf, that can be maintained further. Unfortunately, still no person is seen on horizon who can take maintainership. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Replying to the top of the thread, but the text is actually reply to those people in the thread, who eager for import of new pf from OpenBSD. So, I claim that there is a vast and silent majority of people who simply use pf and do not want the hassle with broken pf.conf. I also claim that there is number of people who utilize pf at larger installations and they were very glad to see pf to scale on multiple CPUs and at least not to freeze the entire traffic for seconds during expiry run. And you claim that there is another large number of people, who want to run newest pf from OpenBSD on FreeBSD, and they do not care about syntax change problems. Unfortunately, we cannot compare our large numbers. Well, you can tell that your number is at least four times bigger than mine, but you will not provide details on how can we check that. :) What can we do in this situation? Thanks to the pfil(9) framework, we can have as much firewalls as we want. You can import new pf keeping the current version intact. There could be some minor problems on decision how to manage two different pfctls, and other utilities, but these are solvable. Let me restate. The FreeBSD version of pf IS NOT on your way of putting OpenBSD version of pf to FreeBSD. What IS your main obstacle in this task is the porting process itself. Try it. Fork FreeBSD in git, mercurial, or simply checkout subversion working directory, then: # cd sys/netpfil # mkdir openbsd-pf # cd openbsd-pf And start working. When you got a buildable and working version[*], post call for testing email to current@ and pf@. After several rounds of testing you will end up with something working. And if we see that the demand for second pf in FreeBSD is real, and you are willing to take maintainership of it, you will be welcome as committer and second pf will be welcome to the tree[**]. Any takers? === [*] Spoiler: usually by that time both FreeBSD tree and pf taken from OpenBSD would diverge and you would need to sync up :) [**] This is my personal opinion, not an official project statement, neither a core team member statement. I expect that there would be resistance against yet-another-packet-filter, that you would need to deal with. But if you got a working code, and you got a userbase of the code, then you have chances to overcome the resistance. And please don't start bikeshedding right now with no code at hand. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Yet another top reply to everyone. If anyone is interested in maintaining our FreeBSD version of pf and taking strategically right (my opinion!) steps in its life, here is a short TODO list: 1) Make Peter and FreeBSD cluster happy. Work on the IPv6 fragments handling. IMHO, the right way would be understanding the problem in its depth and writing code yourself taking ideas or code snippets from OpenBSD. Do not try blindly to replay all their commits over our tree. 2) Do massive API/ABI cleanup. I had started the process, but did less than 10% of it. We need to stop sharing structures between pf internals and ioctls. All kernel structures should live in pfvar.h, and all API in pf.h. The userland utilities should forget pfvar.h. This is huge task. No performance benefit, no new shiny features. But this is strategically correct, if we want a good support of pf in stable branches. Right now we can't merge any feature back due to breaking ABI. Even fixing bugs usually would require ABI breakage. Also, after completing the cleanup and header split further development would become easier. 3) Right now the hot point of contention is the pf_rules_rwlock. It is reader-vs-reader contention on the cache line. Eliminating it would bring a good performance gain on SMP. This would probably require an RCU-like management of rules. Fortunately, the rules in pf a changed in one commit, unlike in ipfw rule by rule. 4) Convert all counters in pf to counter(9). That would be next point of contention once 3) is done. *) Cherry pick any feature you need from OpenBSD. This requires understanding code. Replaying commits won't work. P.S. I'm sorry for saying what should be done without doing that myself. I've spent quite a lot of time on pf, I was promised funding for that and later deceived. Real life changes like new job, children, etc. shifted my focus away from pf and I simply can't dedicate the amount of time to pf that I used before. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
In message CAN6yY1uHJn4xA-5zFr4fZez3FyXi7tT0LmhyR8yWkqG7k1A+=A@mail.gmail.c om , Kevin Oberman writes: On Mon, Jul 28, 2014 at 2:41 AM, Darren Reed darr...@freebsd.org wrote: On 27/07/2014 4:43 AM, Cy Schubert wrote: In message 53d395e4.1070...@fastmail.net, Darren Reed writes: On 24/07/2014 1:42 AM, Cy Schubert wrote: But, lack of ipv6 fragment processing still causes ongoing pain. That'= s our=20 #1 wish list item for the cluster. Taking this discussion slightly sideways but touching on this thread a little, each of our packet filters will need nat66 support too. Pf doesn't support it for sure. I've been told that ipfw may and I suspect ipfilter doesn't as it was on Darren's todo list from 2009. ipfiler 5 handles fragments for ipv6. Switching gears and leaving the discussion of ipv6 fragments to mention nat66. A lot of people have been talking about nat66. I could be wrong but I don't think it can handle nat66. I need to do some testing to verify this. I remember reading on sourceforge that it was on your todo list. It doesn't look like it was checked off as being completed. IPFilter 5 does IPv6 NAT. With the import of 5.1.2, map, rdr and rewrite rules will all work with IPv6 addresses. NAT66 is a specific implementation of IPv6 NAT behaviour. Cheers, Darren And all IPv6 NAT is evil and should be cast into (demonic residence of your choosing) on sight! That I don't disagree with, IPv6 NAT makes no logical sense. Having said that I've received emails asking about NAT66 specifically. It is on people's minds. NAT on IPv6 serves no useful purpose at all. It only serves to complicate things and make clueless security officers happy. It adds zero security. It is a great example of people who assume that NAT is a security feature in IPv4 (it's not) so it should also be in IPv6. Agreed. People think NAT is a security feature (and those same people tout the security of reverse proxies too). It's a checkbox item. The problem is that this meme is so pervasive that even when people understand that it is bad, they still insist on it because there will be an unchecked box on the security checklist for All systems not pubic servers are in RFC1918 space? -- YES NO. The checklist item should be (usually) All systems behind a stateful firewall with an appropriate rule set? -- YES NO as it is a stateful firewall (which is mandatory for NAT that provides all of the security. Exactly! That's pretty much what people who know better are saying. I say usually because the major research lab where I worked ran without a firewall (and probably still does) and little, if any, NAT. It was tested regularly by red teams hired by the feds and they never were able to penetrate anything due to a very aggressive IDS/IPS system, but most people and companies should NOT go this route. I have IPv6 at home (Comcast) and my router runs a stateful firewall with a rule set functionally the same as that used for IPv4 and that provides the protection needed. Not part of this discussion: I think you need both. Firewalls and IPS with IDS. OTOH using NAT as a means of securing a network is illogical. I worked at one place where they would NAT already NATted packets, themselves having previously been processed by previous NAT, all for the sake of security only terribly broke the network to the point there were issues to numerous to discuss in a quick reply here. So putting support for NAT66 or any IPv6 NAT into a firewall is just making things worse. Please don't do it! -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
me wrote: we are talking about NAT64 (IPv6-only datacenter's path to a legacy world), and NPT66 (prefix transalation). I doubt anyone had a traditional NAT in mind. Kevin Oberman wrote: No, all of the messages in the thread are specific about NAT66, not NPT66. NPT66 may have real value. I hate it, but it may well be better than alternatives. [...] Cy Schubert wrote: That I don't disagree with, IPv6 NAT makes no logical sense. Having said that I've received emails asking about NAT66 specifically. It is on people's minds. My impression is that often the term NAT66 is used indiscriminately, even when NPT66 (static prefix translation) is meant. Mark ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Tue, Jul 29, 2014 at 7:48 AM, Mark Martinec mark.martinec+free...@ijs.si wrote: me wrote: we are talking about NAT64 (IPv6-only datacenter's path to a legacy world), and NPT66 (prefix transalation). I doubt anyone had a traditional NAT in mind. Kevin Oberman wrote: No, all of the messages in the thread are specific about NAT66, not NPT66. NPT66 may have real value. I hate it, but it may well be better than alternatives. [...] Cy Schubert wrote: That I don't disagree with, IPv6 NAT makes no logical sense. Having said that I've received emails asking about NAT66 specifically. It is on people's minds. My impression is that often the term NAT66 is used indiscriminately, even when NPT66 (static prefix translation) is meant. Mark I would hope that is not the case. While NAT66 is well known and has been a topic of discussion for years, NPT66 is relatively new. It does share many concepts with NAT66 (and, most likely implementations also share code), but does not require any state, making it vastly less complex and no longer breaks point to point networking. The names look similar, which may result in unfortunate confusion, but NPT66 may be the bast solution to a real problem and it does not create the issues of NAT66. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 29 July 2014 09:54, Kevin Oberman rkober...@gmail.com wrote: On Tue, Jul 29, 2014 at 7:48 AM, Mark Martinec mark.martinec+free...@ijs.si wrote: me wrote: we are talking about NAT64 (IPv6-only datacenter's path to a legacy world), and NPT66 (prefix transalation). I doubt anyone had a traditional NAT in mind. Kevin Oberman wrote: No, all of the messages in the thread are specific about NAT66, not NPT66. NPT66 may have real value. I hate it, but it may well be better than alternatives. [...] Cy Schubert wrote: That I don't disagree with, IPv6 NAT makes no logical sense. Having said that I've received emails asking about NAT66 specifically. It is on people's minds. My impression is that often the term NAT66 is used indiscriminately, even when NPT66 (static prefix translation) is meant. Mark I would hope that is not the case. While NAT66 is well known and has been a topic of discussion for years, NPT66 is relatively new. It does share many concepts with NAT66 (and, most likely implementations also share code), but does not require any state, making it vastly less complex and no longer breaks point to point networking. The names look similar, which may result in unfortunate confusion, but NPT66 may be the bast solution to a real problem and it does not create the issues of NAT66. Course it will. All those bad protocols that embed IP addresses in them to connect to. Or wait, is everything written these days mindful of NAT/NPT and tries desperately to work around it? Hm... -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 27/07/2014 4:43 AM, Cy Schubert wrote: In message 53d395e4.1070...@fastmail.net, Darren Reed writes: On 24/07/2014 1:42 AM, Cy Schubert wrote: But, lack of ipv6 fragment processing still causes ongoing pain. That'= s our=20 #1 wish list item for the cluster. Taking this discussion slightly sideways but touching on this thread a little, each of our packet filters will need nat66 support too. Pf doesn't support it for sure. I've been told that ipfw may and I suspect ipfilter doesn't as it was on Darren's todo list from 2009. ipfiler 5 handles fragments for ipv6. Switching gears and leaving the discussion of ipv6 fragments to mention nat66. A lot of people have been talking about nat66. I could be wrong but I don't think it can handle nat66. I need to do some testing to verify this. I remember reading on sourceforge that it was on your todo list. It doesn't look like it was checked off as being completed. IPFilter 5 does IPv6 NAT. With the import of 5.1.2, map, rdr and rewrite rules will all work with IPv6 addresses. NAT66 is a specific implementation of IPv6 NAT behaviour. Cheers, Darren ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Mon, Jul 28, 2014 at 2:41 AM, Darren Reed darr...@freebsd.org wrote: On 27/07/2014 4:43 AM, Cy Schubert wrote: In message 53d395e4.1070...@fastmail.net, Darren Reed writes: On 24/07/2014 1:42 AM, Cy Schubert wrote: But, lack of ipv6 fragment processing still causes ongoing pain. That'= s our=20 #1 wish list item for the cluster. Taking this discussion slightly sideways but touching on this thread a little, each of our packet filters will need nat66 support too. Pf doesn't support it for sure. I've been told that ipfw may and I suspect ipfilter doesn't as it was on Darren's todo list from 2009. ipfiler 5 handles fragments for ipv6. Switching gears and leaving the discussion of ipv6 fragments to mention nat66. A lot of people have been talking about nat66. I could be wrong but I don't think it can handle nat66. I need to do some testing to verify this. I remember reading on sourceforge that it was on your todo list. It doesn't look like it was checked off as being completed. IPFilter 5 does IPv6 NAT. With the import of 5.1.2, map, rdr and rewrite rules will all work with IPv6 addresses. NAT66 is a specific implementation of IPv6 NAT behaviour. Cheers, Darren And all IPv6 NAT is evil and should be cast into (demonic residence of your choosing) on sight! NAT on IPv6 serves no useful purpose at all. It only serves to complicate things and make clueless security officers happy. It adds zero security. It is a great example of people who assume that NAT is a security feature in IPv4 (it's not) so it should also be in IPv6. The problem is that this meme is so pervasive that even when people understand that it is bad, they still insist on it because there will be an unchecked box on the security checklist for All systems not pubic servers are in RFC1918 space? -- YES NO. The checklist item should be (usually) All systems behind a stateful firewall with an appropriate rule set? -- YES NO as it is a stateful firewall (which is mandatory for NAT that provides all of the security. I say usually because the major research lab where I worked ran without a firewall (and probably still does) and little, if any, NAT. It was tested regularly by red teams hired by the feds and they never were able to penetrate anything due to a very aggressive IDS/IPS system, but most people and companies should NOT go this route. I have IPv6 at home (Comcast) and my router runs a stateful firewall with a rule set functionally the same as that used for IPv4 and that provides the protection needed. So putting support for NAT66 or any IPv6 NAT into a firewall is just making things worse. Please don't do it! -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Mon, Jul 28, 2014 at 2:41 AM, Darren Reed darr...@freebsd.org wrote: [...] IPFilter 5 does IPv6 NAT. With the import of 5.1.2, map, rdr and rewrite rules will all work with IPv6 addresses. NAT66 is a specific implementation of IPv6 NAT behaviour. 2014-07-29 00:07 Kevin Oberman wrote: And all IPv6 NAT is evil and should be cast into (demonic residence of your choosing) on sight! NAT on IPv6 serves no useful purpose at all. It only serves to complicate things and make clueless security officers happy. It adds zero security. It is a great example of people who assume that NAT is a security feature in IPv4 (it's not) so it should also be in IPv6. The problem is that this meme is so pervasive that even when people understand that it is bad, they still insist on it because there will be an unchecked box on the security checklist for All systems not pubic servers are in RFC1918 space? -- YES NO. The checklist item should be (usually) All systems behind a stateful firewall with an appropriate rule set? -- YES NO as it is a stateful firewall (which is mandatory for NAT that provides all of the security. I say usually because the major research lab where I worked ran without a firewall (and probably still does) and little, if any, NAT. It was tested regularly by red teams hired by the feds and they never were able to penetrate anything due to a very aggressive IDS/IPS system, but most people and companies should NOT go this route. I have IPv6 at home (Comcast) and my router runs a stateful firewall with a rule set functionally the same as that used for IPv4 and that provides the protection needed. So putting support for NAT66 or any IPv6 NAT into a firewall is just making things worse. Please don't do it! -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com You are missing the point, we are talking about NAT64 (IPv6-only datacenter's path to a legacy world), and NPT66 (prefix transalation). I doubt anyone had a traditional NAT in mind. Consider a small site with uplinks to two service providers: it can use ULA internally and translate prefix on each uplink. Please see these short blogs: - To ULA or not to ULA, That’s the Question http://blog.ipspace.net/2013/09/to-ula-or-not-to-ula-thats-question.html - I Say ULA, You Hear NAT http://blog.ipspace.net/2014/01/i-say-ula-you-hear-nat.html - PA, PI or ULA IPv6 Address Space? It depends http://blog.ipspace.net/2014/01/pa-pi-or-ula-ipv6-address-space-it.html - Source IPv6 Address Selection Saves the Day http://blog.ipspace.net/2014/01/source-ipv6-address-selection-saves-day.html Mark ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Mon, Jul 28, 2014 at 4:21 PM, Mark Martinec mark.martinec+free...@ijs.si wrote: On Mon, Jul 28, 2014 at 2:41 AM, Darren Reed darr...@freebsd.org wrote: [...] IPFilter 5 does IPv6 NAT. With the import of 5.1.2, map, rdr and rewrite rules will all work with IPv6 addresses. NAT66 is a specific implementation of IPv6 NAT behaviour. 2014-07-29 00:07 Kevin Oberman wrote: And all IPv6 NAT is evil and should be cast into (demonic residence of your choosing) on sight! NAT on IPv6 serves no useful purpose at all. It only serves to complicate things and make clueless security officers happy. It adds zero security. It is a great example of people who assume that NAT is a security feature in IPv4 (it's not) so it should also be in IPv6. The problem is that this meme is so pervasive that even when people understand that it is bad, they still insist on it because there will be an unchecked box on the security checklist for All systems not pubic servers are in RFC1918 space? -- YES NO. The checklist item should be (usually) All systems behind a stateful firewall with an appropriate rule set? -- YES NO as it is a stateful firewall (which is mandatory for NAT that provides all of the security. I say usually because the major research lab where I worked ran without a firewall (and probably still does) and little, if any, NAT. It was tested regularly by red teams hired by the feds and they never were able to penetrate anything due to a very aggressive IDS/IPS system, but most people and companies should NOT go this route. I have IPv6 at home (Comcast) and my router runs a stateful firewall with a rule set functionally the same as that used for IPv4 and that provides the protection needed. So putting support for NAT66 or any IPv6 NAT into a firewall is just making things worse. Please don't do it! -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com You are missing the point, we are talking about NAT64 (IPv6-only datacenter's path to a legacy world), and NPT66 (prefix transalation). I doubt anyone had a traditional NAT in mind. Consider a small site with uplinks to two service providers: it can use ULA internally and translate prefix on each uplink. Please see these short blogs: - To ULA or not to ULA, That’s the Question http://blog.ipspace.net/2013/09/to-ula-or-not-to-ula-thats-question.html - I Say ULA, You Hear NAT http://blog.ipspace.net/2014/01/i-say-ula-you-hear-nat.html - PA, PI or ULA IPv6 Address Space? It depends http://blog.ipspace.net/2014/01/pa-pi-or-ula-ipv6-address-space-it.html - Source IPv6 Address Selection Saves the Day http://blog.ipspace.net/2014/01/source-ipv6-address- selection-saves-day.html Mark Mark, No, all of the messages in the thread are specific about NAT66, not NPT66. NPT66 may have real value. I hate it, but it may well be better than alternatives. It addresses an issue I have had with many of the IPv6 purists. I do think some of the arguments for it are over-stated. Getting a /48 is trivial, but getting it routed is not, so there is a real issue, but it remains unclear how bit the issue really is. For most users, multi-homing is fine, but not for servers. But smaller companies often farm out their servers, so it's not an issue for them. The one really significant issue I accept as real is the expansion of the routing tables. While the IPv6 table is still fairly small (~17k) , it is growing and has the potential to exceed the size of the IPv4 table (500K) which continues to grow due to deaggregation. For those not dealing with backbone BGP, the issues include handling large numbers of prefixes and the stability of routing tables (both RIBs and FIBs) with all of the churn . Since I have retired, I have not been involved in IPv6 implementation or technical discussion, but I started dealing with it back in the 1990s and, until I retired in 2011 I had the first computer (a DEC Alpha) that had an ARIN assigned IPv6 address sitting under my desk, hershey.es.net. (No, it was no longer in use.) I also opposed ULA. While I understood the arguments in its favor, I have still do not agree with them. I think ULA is simply a bad idea, but it is there and we will have to deal with it... forever. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 24/07/2014 1:42 AM, Cy Schubert wrote: But, lack of ipv6 fragment processing still causes ongoing pain. That'= s our=20 #1 wish list item for the cluster. Taking this discussion slightly sideways but touching on this thread a little, each of our packet filters will need nat66 support too. Pf doesn't support it for sure. I've been told that ipfw may and I suspect ipfilter doesn't as it was on Darren's todo list from 2009. ipfiler 5 handles fragments for ipv6. Darren ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
We've already heard of Henning offering to help port a new pf but the olive branch has been extended even further. He responded to some comments of mine on twitter: @HenningBrauer: @rhymebyter @feldpos I offered help/advice to whomever seriously attempts to update pf in @dragonflybsd AND @freebsd. @HenningBrauer: @feldpos it takes someone in freebsd/netbsd/dragonfly to update their ancient pf versions, then code can flow bidirectional Technical hurdles aside, that sounds like the beginning of an OpenPf to me... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
The flow in both directions has to include: * better locking / parallelism * virtualised forwarding support (ie, vimage) If he's happy to include some stubs for that, then sure. I think both dfbsd and freebsd can use the same pf. -a On 26 July 2014 08:27, Mark Felder f...@freebsd.org wrote: We've already heard of Henning offering to help port a new pf but the olive branch has been extended even further. He responded to some comments of mine on twitter: @HenningBrauer: @rhymebyter @feldpos I offered help/advice to whomever seriously attempts to update pf in @dragonflybsd AND @freebsd. @HenningBrauer: @feldpos it takes someone in freebsd/netbsd/dragonfly to update their ancient pf versions, then code can flow bidirectional Technical hurdles aside, that sounds like the beginning of an OpenPf to me... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
In message 53d395e4.1070...@fastmail.net, Darren Reed writes: On 24/07/2014 1:42 AM, Cy Schubert wrote: But, lack of ipv6 fragment processing still causes ongoing pain. That'= s our=20 #1 wish list item for the cluster. Taking this discussion slightly sideways but touching on this thread a little, each of our packet filters will need nat66 support too. Pf doesn't support it for sure. I've been told that ipfw may and I suspect ipfilter doesn't as it was on Darren's todo list from 2009. ipfiler 5 handles fragments for ipv6. Switching gears and leaving the discussion of ipv6 fragments to mention nat66. A lot of people have been talking about nat66. I could be wrong but I don't think it can handle nat66. I need to do some testing to verify this. I remember reading on sourceforge that it was on your todo list. It doesn't look like it was checked off as being completed. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Sorry for the late reply. It's a busy time right now. In message 53d0239d.1050...@a1poweruser.com, Fbsd8 writes: Cy Schubert wrote: On 20.07.2014 18:15, Maxim Khitrov wrote: In my opinion, the way forward is to forget (at least temporarily) the SMP changes, bring pf in sync with OpenBSD, put a policy in place to follow their releases as closely as possible, and then try to reintroduce all the SMP work. I think the latter has to be done upstream, otherwise it'll always be a story of diverging codebases. Furthermore, if FreeBSD developers were willing to spend some time improving pf performance on OpenBSD, then Henning and other OpenBSD developers might be more receptive to changes that make the porting process easier. Even if you just drop current PF from FreeBSD, there is nobody, who want to port new PF from OpenBSD. And this is not easy task, as you may think. Gleb has worked on rewriting PF more than half year. So, return back all improvements after import will be hard enough and, again, nobody want to do it. :) One way or another something needs to be done and agreed it would be a lot of work. Our options are, a) Import OpenBSD pf thereby throwing away our current investment in pf. All our work to get it up to snuff with our IP stack, SMP, and VIMAGE would be all for naught. We do get a new pf though. Won't be a quality port though. Personally, not my #1 option. b) Merge updates from OpenBSD pf to our pf. Once again a lot of work but we do save the work we put into our pf. Once again a lot of work. We'd be introducing incompatibility. c) Do nothing. It goes without saying that pf would suffer rot and eventually we would need to do something. d) Yank pf from tree. An option but probably not a great one. We do have two other packet filters in the kernel (ipfw and ipfilter) however they are different beasts with different capabilities. I think the reason we have the packet filters we do have is for the capabilities they bring to the table. I for one have run more than one in the same kernel because each has different capabilities. e) We could add capability to pf on a piecemeal basis. Option (b) but as time permits. Remember, people have jobs and commitments. Funding would help address this. f) Finally, how does NetBSD's npf compare to OpenBSD's pf? Is it more compatible with our IP stack? Could this be an option? Anything we do should work with VIMAGE and be able to handle nat66 as well. Hello Cy; Finally a voice I recognize. If I remember correctly you stepped up to the plate earlier this year and did for ipfilter the same kind of things Last autumn. this thread is talking about for pf. IE; apply upstream maintenance and convert to FreeBSD standards. I think your work was a BSD fork of Darrow's ipfilter which from this point on all upstream maintenance must be hand merged into the BSD fork. I am a long time ipfilter user and Actually we did not fork ipfilter. It's simply included into our tree, with a few modifications. thank you for your dedication and work ethics getting the updated ipfilter into 10.0 and 9.3 so quickly. You're welcome. I too am a long time ipfilter user (Solaris and FreeBSD). So as someone who has been there and done that already you have unique experience to really know the size of the task in hours to accomplish a pf upgrade. Could you list the tasks and hours it took you to perform the ipfilter upgrade so readers can have a real insight into what they are asking for? The experience is not unique. Every developer pretty much follows the same process when importing code into the tree. As for tasks, the ipfilter import was relatively simple compared to some others. Remember, ipfilter was designed to be run on any of the BSDs, SunOS, Solaris, and HP/UX, IRIX, and Tru64 UNIX. That made upgrading from 4.1.28 to 5.1.2 simpler than pf which is written only for OpenBSD and its stack. I agree with your option e above, but I would re-word it this way. Using the pf fork we already have in place, hand merge upstream differences in piecemeal chunks as time permits. The openbsd new syntax being the first chunk, closely followed by VIMAGE awareness. Personally I would choose option e because of $JOB and $FAMILY commitments. Adding the new OpenBSD syntax may be more difficult than we might think. The new syntax may be related to a new internal structure of pf. If the new pf is a rewrite (ipfilter 5.1.2 was a rewrite of large chunks of code), then you have no option but to do a wholesale import and retrofit our mods back into it, if they would even fit at all. I think the first task for anyone taking this on would be to familiarize oneself with the current pf code in FreeBSD and what was done to make it fit and to enhance it, then familiarize oneself with the new pf to get a feel for what work would be
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Jul 23, 2014, at 15:59, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote: There was (is?) another case that in certain situations with certain pf options IPv6/ULP packets would not pass or get corrupted. I think no one who experienced it never tracked it down to the code but I am sure there are PRs for this; best bet is that not all header sizes are equal and length/offsets into IPv6 packets are different to IPv4, especially when you scrub. scrub reassemble tcp breaks all ipv6 tcp traffic since FreeBSD 9.0. Well, not entirely breaks but things seem to be going at a rate of a poor dialup connection. This is similar to what I've experienced with pf + tso on Xen. Related? Possibly! I'd hazard a guess the reassembling of tcp on IPv6 is breaking checksums? Upstream pf from OpenBSD has removed this feature entirely and (I believe) reworked their scrubbing, but I don't know the details. I can confirm that when reassemble tcp existed on OpenBSD it never broke traffic for me. Synproxy and IPv6 was also broken last I knew. I can't remember the symptoms, but it was probably nothing works. I recall synproxy has always been one of those you're gonna shoot your eye out kid features, but some people have used it successfully. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Jul 24, 2014, at 13:43, Mark Felder f...@freebsd.org wrote: Upstream pf from OpenBSD has removed this feature entirely and (I believe) reworked their scrubbing, but I don't know the details. I can confirm that when reassemble tcp existed on OpenBSD it never broke traffic for me. I'm wrong; reassemble tcp still exists upstream. I must be thinking of something else that has since been removed but exists in our version. Oh well. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Wednesday 23 July 2014 20:59:19 Bjoern A. Zeeb wrote: On 23 Jul 2014, at 20:41 , Allan Jude allanj...@freebsd.org wrote: On 2014-07-23 16:38, Bjoern A. Zeeb wrote: On 23 Jul 2014, at 15:42 , Cy Schubert cy.schub...@komquats.com wrote: Taking this discussion slightly sideways but touching on this thread a little, each of our packet filters will need nat66 support too. Pf doesn't support it for sure. I've been told that ipfw may and I suspect ipfilter doesn't as it was on Darren's todo list from 2009. our pf does support IPv6 prefix rewriting quite nicely and has for years. Bjoern: What IPv6 stuff does our pf not do well? I think the most pressing, as Peter said, is fragment handling, though a good fraction of major content providers seems to do mss clamping to a min IPv6 mtu on IPv6 and drop fragments at the edge (not much different to IPv4, which makes you wonder?).Whoever is clever will think of how many different queueing and fragment handling implementations we need in the kernel, and how often we have to do it on an end node that might also run a firewall, pick one we have, turn it into a library thing, apply it to all places, and then add the latest IETF suggestions on top of it. Correct. There is code in the openbsd cvs history where they added it while the internal APIs looked similar enough to ours. It's simpler than ipv4 reassembly - taking advantage of things like overlapping fragments not being allowed. I'm almost desperate enough to take a shot at it myself, but mbufs and I do not get along. Nobody wants code I've touched to be in the tree if mbufs are involved. The initial commits.. first the supporting changes: (refactor code for reuse) http://openbsd.cs.toronto.edu/cgi-bin/cvsweb/src/sys/net/pf_norm.c.diff?r1=1.128r2=1.129 (add ipv6 defrag/refrag) http://openbsd.cs.toronto.edu/cgi-bin/cvsweb/src/sys/net/pf_norm.c.diff?r1=1.129r2=1.130 Then they added the code to defragment/refragment: (pf_test6 defrag/refrag) http://openbsd.cs.toronto.edu/cgi-bin/cvsweb/src/sys/net/pf.c.diff?r1=1.729r2=1.730 The catch is that they fixed a lot of edge cases so one needs to follow the history forward a bit to make sure it it's covered. The other problem is our codebase is even older than when this was added so some looking at older commits is required. In the time since the feature was added, they have refactored it a few times and merged the two code paths for ipv4 and ipv6. It bears no resemblance to what we have in our tree. The killer reason why this is a problem that needs to be solved.. IPv6 + DNSSEC exercises this code a lot. Performance isn't a factor - it's basic functionality that's at stake. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 signature.asc Description: This is a digitally signed message part.
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 21/07/2014 5:14 AM, Eric Masson wrote: krad kra...@gmail.com writes: Hi, I really like the idea of the openpf version, that has been mentioned in this thread. It would be nice but as it's been written in this thread, Open Free internals are quite different beasts, goals are different on both platforms, so I doubt OpenPF will exist in the future. It would be awesome if it ended up as a supported linux thing as well, so the world could be rid of iptables. Linux world will get rid of iptables one of these days, nftables inclusion in mainline is a clear signal. And the design behind nftables is similar to that of NetBSD's npf. Darren ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
In message CAJ-Vmo=_vLkMZn02EPUmpvqugcT8ga1_Kqs=XU49SGUNGEO0Pw@mail.gmail.c om , Adrian Chadd writes: On 18 July 2014 07:34, krad kra...@gmail.com wrote: that is true and I have not problem using man pages, however thats not the way most of the world work and search engines arent exactly new either. We should be trying to engage more people not less, and part of that is reaching out. Then do the port and maintain it. The problem isn't the desire to keep things up to date, it's a lack of people who want that _and_ are willing/able to do it _and_ are funded somehow. Funding is the issue. Sure, some of us maintain software because a personal need however without funding one has to fit maintaining software into whatever time is left. For those of us who do this without funding you manage to squeeze in an hour here or there. So, please step up! We'll all love you for it. Many hands make light work. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
In message 20381608.hhy3qfh...@overcee.wemm.org, Peter Wemm writes: On Saturday 19 July 2014 13:06:52 Baptiste Daroussin wrote: On Fri, Jul 18, 2014 at 03:22:18PM -0400, Allan Jude wrote: On 2014-07-18 15:07, Adrian Chadd wrote: On 18 July 2014 07:34, krad kra...@gmail.com wrote: that is true and I have not problem using man pages, however tha= ts not the way most of the world work and search engines arent exactly new = either. We should be trying to engage more people not less, and part of tha= t is reaching out. =20 Then do the port and maintain it. =20 The problem isn't the desire to keep things up to date, it's a la= ck of people who want that _and_ are willing/able to do it _and_ are fu= nded somehow. =20 So, please step up! We'll all love you for it. =20 =20 =20 -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org =20 At vBSDCon Bapt@ volunteered to port the newer pf back to FreeBSD, = after spending some hours driving with Henning. =20 I tried and broke pf for month and my changes have been reverted, thi= s is not as simple as it looks like, our code as diverge a lot in some par= t and we do support things that openbsd does not (vimage). Sync features re= quires us to be very careful, my priorities went elsewhere since that time, = so now I will probably only focus on bringing features I care about, and not= the entirely new pf. =20 So no do not count me as volunteer to maintain pf, I ll probably do s= ome work but not a full sync. If anyone is looking for a really useful chunk to work on, please go ba= ck over=20 the pf history in openbsd and find where they added ipv6 fragment suppo= rt. It=20 was fairly well contained and didn't appear to be a big deal to port. = They=20 did do something with mbuf tags that I'm suspicious of though. IPv6 fragments are the biggest pain point we have on the freebsd.org cl= uster -=20 yes, we use pf and IPv6 extensively, but dns with ipv6 involved is real= ly=20 painful without fragment support. We sort-of work around it by using dedicated IPv6 address that has noth= ing but=20 the dns resolver clients and allow ipv6 fragments to it. Its not idea= l but=20 it gets over the worst problems. The other thing we had to do for usability is stop state tracking for u= dp dns=20 =2D the sheer update rate was causing collisions and state drops / resets= of=20 other connections to the point of being really hard to use. Those two tweaks - stopping heavy dns use from thrashing the state tabl= es, and=20 having a safe place to send fragments makes it quite usable for freebsd= .org. But, lack of ipv6 fragment processing still causes ongoing pain. That'= s our=20 #1 wish list item for the cluster. Taking this discussion slightly sideways but touching on this thread a little, each of our packet filters will need nat66 support too. Pf doesn't support it for sure. I've been told that ipfw may and I suspect ipfilter doesn't as it was on Darren's todo list from 2009. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
In message 53ccf596.1070...@yandex.ru, Andrey V. Elsukov writes: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EITUmaAVUtsHLdssNwHpA0G0W8jTQ9d3L Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 20.07.2014 18:15, Maxim Khitrov wrote: In my opinion, the way forward is to forget (at least temporarily) the SMP changes, bring pf in sync with OpenBSD, put a policy in place to follow their releases as closely as possible, and then try to reintroduce all the SMP work. I think the latter has to be done upstream, otherwise it'll always be a story of diverging codebases. Furthermore, if FreeBSD developers were willing to spend some time improving pf performance on OpenBSD, then Henning and other OpenBSD developers might be more receptive to changes that make the porting process easier. Even if you just drop current PF from FreeBSD, there is nobody, who want to port new PF from OpenBSD. And this is not easy task, as you may think. Gleb has worked on rewriting PF more than half year. So, return back all improvements after import will be hard enough and, again, nobody want to do it. :) One way or another something needs to be done and agreed it would be a lot of work. Our options are, a) Import OpenBSD pf thereby throwing away our current investment in pf. All our work to get it up to snuff with our IP stack, SMP, and VIMAGE would be all for naught. We do get a new pf though. Won't be a quality port though. Personally, not my #1 option. b) Merge updates from OpenBSD pf to our pf. Once again a lot of work but we do save the work we put into our pf. Once again a lot of work. We'd be introducing incompatibility. c) Do nothing. It goes without saying that pf would suffer rot and eventually we would need to do something. d) Yank pf from tree. An option but probably not a great one. We do have two other packet filters in the kernel (ipfw and ipfilter) however they are different beasts with different capabilities. I think the reason we have the packet filters we do have is for the capabilities they bring to the table. I for one have run more than one in the same kernel because each has different capabilities. e) We could add capability to pf on a piecemeal basis. Option (b) but as time permits. Remember, people have jobs and commitments. Funding would help address this. f) Finally, how does NetBSD's npf compare to OpenBSD's pf? Is it more compatible with our IP stack? Could this be an option? Anything we do should work with VIMAGE and be able to handle nat66 as well. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
In message alpine.lrh.2.11.1407201430030.2...@nber7.nber.org, Daniel Feenberg writes: On Sun, 20 Jul 2014, Lars Engels wrote: On Sun, Jul 20, 2014 at 12:18:54PM +0100, krad wrote: all of that is true, but you are missing the point. Having two versions of pf on the bsd's at the user level, is a bad thing. It confuses people, which puts them off. Its a classic case of divide an conquer for other platforms. I really like the idea of the openpf version, that has been mentioned in this thread. It would be awesome if it ended up as a supporte d linux thing as well, so the world could be rid of iptables. However i gues s thats just an unrealistic dream And you don't seem to get the point that _someone_ has to do the work. No one has stepped up so far, so nothing is going to change. No one with authority has yet said that If an updated pf were available, would be welcomed. Rather they have said An updated pf would not be suitable, as it would be incompatible with existing configuration files. If the latter is indeed the case, there is little incentive for anyone to go to the effort of porting the newer pf. After all, the reward for the work is chiefly in glory, and if there is to be no glory, the work is unlikely to be done. I disagree. One does not do this for the glory. One does this because the nail hurts enough to do something about it. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 23 Jul 2014, at 15:42 , Cy Schubert cy.schub...@komquats.com wrote: Taking this discussion slightly sideways but touching on this thread a little, each of our packet filters will need nat66 support too. Pf doesn't support it for sure. I've been told that ipfw may and I suspect ipfilter doesn't as it was on Darren's todo list from 2009. our pf does support IPv6 prefix rewriting quite nicely and has for years. — Bjoern A. Zeeb Come on. Learn, goddamn it., WarGames, 1983 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 2014-07-23 16:38, Bjoern A. Zeeb wrote: On 23 Jul 2014, at 15:42 , Cy Schubert cy.schub...@komquats.com wrote: Taking this discussion slightly sideways but touching on this thread a little, each of our packet filters will need nat66 support too. Pf doesn't support it for sure. I've been told that ipfw may and I suspect ipfilter doesn't as it was on Darren's todo list from 2009. our pf does support IPv6 prefix rewriting quite nicely and has for years. — Bjoern A. Zeeb Come on. Learn, goddamn it., WarGames, 1983 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Bjoern: What IPv6 stuff does our pf not do well? -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 23 Jul 2014, at 20:41 , Allan Jude allanj...@freebsd.org wrote: On 2014-07-23 16:38, Bjoern A. Zeeb wrote: On 23 Jul 2014, at 15:42 , Cy Schubert cy.schub...@komquats.com wrote: Taking this discussion slightly sideways but touching on this thread a little, each of our packet filters will need nat66 support too. Pf doesn't support it for sure. I've been told that ipfw may and I suspect ipfilter doesn't as it was on Darren's todo list from 2009. our pf does support IPv6 prefix rewriting quite nicely and has for years. Bjoern: What IPv6 stuff does our pf not do well? I think the most pressing, as Peter said, is fragment handling, though a good fraction of major content providers seems to do mss clamping to a min IPv6 mtu on IPv6 and drop fragments at the edge (not much different to IPv4, which makes you wonder?).Whoever is clever will think of how many different queueing and fragment handling implementations we need in the kernel, and how often we have to do it on an end node that might also run a firewall, pick one we have, turn it into a library thing, apply it to all places, and then add the latest IETF suggestions on top of it. There was (is?) another case that in certain situations with certain pf options IPv6/ULP packets would not pass or get corrupted. I think no one who experienced it never tracked it down to the code but I am sure there are PRs for this; best bet is that not all header sizes are equal and length/offsets into IPv6 packets are different to IPv4, especially when you scrub. Apart from that my knowledge of pf is diminishing. — Bjoern A. Zeeb Come on. Learn, goddamn it., WarGames, 1983 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Cy Schubert wrote: In message 53ccf596.1070...@yandex.ru, Andrey V. Elsukov writes: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EITUmaAVUtsHLdssNwHpA0G0W8jTQ9d3L Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 20.07.2014 18:15, Maxim Khitrov wrote: In my opinion, the way forward is to forget (at least temporarily) the SMP changes, bring pf in sync with OpenBSD, put a policy in place to follow their releases as closely as possible, and then try to reintroduce all the SMP work. I think the latter has to be done upstream, otherwise it'll always be a story of diverging codebases. Furthermore, if FreeBSD developers were willing to spend some time improving pf performance on OpenBSD, then Henning and other OpenBSD developers might be more receptive to changes that make the porting process easier. Even if you just drop current PF from FreeBSD, there is nobody, who want to port new PF from OpenBSD. And this is not easy task, as you may think. Gleb has worked on rewriting PF more than half year. So, return back all improvements after import will be hard enough and, again, nobody want to do it. :) One way or another something needs to be done and agreed it would be a lot of work. Our options are, a) Import OpenBSD pf thereby throwing away our current investment in pf. All our work to get it up to snuff with our IP stack, SMP, and VIMAGE would be all for naught. We do get a new pf though. Won't be a quality port though. Personally, not my #1 option. b) Merge updates from OpenBSD pf to our pf. Once again a lot of work but we do save the work we put into our pf. Once again a lot of work. We'd be introducing incompatibility. c) Do nothing. It goes without saying that pf would suffer rot and eventually we would need to do something. d) Yank pf from tree. An option but probably not a great one. We do have two other packet filters in the kernel (ipfw and ipfilter) however they are different beasts with different capabilities. I think the reason we have the packet filters we do have is for the capabilities they bring to the table. I for one have run more than one in the same kernel because each has different capabilities. e) We could add capability to pf on a piecemeal basis. Option (b) but as time permits. Remember, people have jobs and commitments. Funding would help address this. f) Finally, how does NetBSD's npf compare to OpenBSD's pf? Is it more compatible with our IP stack? Could this be an option? Anything we do should work with VIMAGE and be able to handle nat66 as well. Hello Cy; Finally a voice I recognize. If I remember correctly you stepped up to the plate earlier this year and did for ipfilter the same kind of things this thread is talking about for pf. IE; apply upstream maintenance and convert to FreeBSD standards. I think your work was a BSD fork of Darrow's ipfilter which from this point on all upstream maintenance must be hand merged into the BSD fork. I am a long time ipfilter user and thank you for your dedication and work ethics getting the updated ipfilter into 10.0 and 9.3 so quickly. So as someone who has been there and done that already you have unique experience to really know the size of the task in hours to accomplish a pf upgrade. Could you list the tasks and hours it took you to perform the ipfilter upgrade so readers can have a real insight into what they are asking for? I agree with your option e above, but I would re-word it this way. Using the pf fork we already have in place, hand merge upstream differences in piecemeal chunks as time permits. The openbsd new syntax being the first chunk, closely followed by VIMAGE awareness. When it comes to someone volunteering to do the work, many of us would step up, but the fact is only a very very few people have the coding and kernel knowledge to even consider doing this. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Also, the openbsd stack has some essential features missing in freebsd, like mpls and md5 auth for bgp sessions. I use MD5 auth for BGP sessions every day (and have been doing so for several releases). One could definitely wish for better integration - having to specify MD5 key both in /etc/ipsec.conf and in the Quagga bgpd config is not nice. But it works. As far as I know you can only send out correctly authed stuff but not validate incoming. Has that changed? Have a look at tcp_signature_verify(), called from tcp_input.c. Added in r221023, see http://svnweb.freebsd.org/base/head/sys/netinet/tcp_input.c?view=log Steinar Haug, Nethelp consulting, sth...@nethelp.no -- Revision 221023 - (view) (download) (annotate) - [select for diffs] Modified Mon Apr 25 17:13:40 2011 UTC (3 years, 2 months ago) by attilio File length: 106717 byte(s) Diff to previous 220560 Add the possibility to verify MD5 hash of incoming TCP packets. As long as this is a costy function, even when compiled in (along with the option TCP_SIGNATURE), it can be disabled via the net.inet.tcp.signature_verify_input sysctl. Sponsored by: Sandvine Incorporated Reviewed by:emaste, bz MFC after: 2 weeks ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 20.07.2014 18:15, Maxim Khitrov wrote: In my opinion, the way forward is to forget (at least temporarily) the SMP changes, bring pf in sync with OpenBSD, put a policy in place to follow their releases as closely as possible, and then try to reintroduce all the SMP work. I think the latter has to be done upstream, otherwise it'll always be a story of diverging codebases. Furthermore, if FreeBSD developers were willing to spend some time improving pf performance on OpenBSD, then Henning and other OpenBSD developers might be more receptive to changes that make the porting process easier. Even if you just drop current PF from FreeBSD, there is nobody, who want to port new PF from OpenBSD. And this is not easy task, as you may think. Gleb has worked on rewriting PF more than half year. So, return back all improvements after import will be hard enough and, again, nobody want to do it. :) -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Mon, Jul 21, 2014 at 8:56 AM, sth...@nethelp.no wrote: Also, the openbsd stack has some essential features missing in freebsd, like mpls and md5 auth for bgp sessions. I use MD5 auth for BGP sessions every day (and have been doing so for several releases). One could definitely wish for better integration - having to specify MD5 key both in /etc/ipsec.conf and in the Quagga bgpd config is not nice. But it works. As far as I know you can only send out correctly authed stuff but not validate incoming. Has that changed? Have a look at tcp_signature_verify(), called from tcp_input.c. Added in r221023, see http://svnweb.freebsd.org/base/head/sys/netinet/tcp_input.c?view=log Steinar Haug, Nethelp consulting, sth...@nethelp.no -- Revision 221023 - (view) (download) (annotate) - [select for diffs] Modified Mon Apr 25 17:13:40 2011 UTC (3 years, 2 months ago) by attilio File length: 106717 byte(s) Diff to previous 220560 Add the possibility to verify MD5 hash of incoming TCP packets. As long as this is a costy function, even when compiled in (along with the option TCP_SIGNATURE), it can be disabled via the net.inet.tcp.signature_verify_input sysctl. Sponsored by: Sandvine Incorporated Reviewed by:emaste, bz MFC after: 2 weeks I stand corrected. Excellent news ( for me, that is) :) Best regards Andeas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: Future of pf / firewall in FreeBSD ? - does it have one ?
There is no doubt that PF is a really good firewall, But we should noticed that there is an ipfw which is originally from FreeBSD while PF is from OpenBSD. If there is a requirement that PF can meet but ipfw cannot, then I think it is better to improve the ipfw. But if you just like the PF style, then I think choose OpenBSD is the better solution. Actually OpenBSD is another really good operating system. Like myself, I like CentOS and ipfw, so no choice :) -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- curr...@freebsd.org] On Behalf Of Andreas Nilsson Sent: 21 July, 2014 19:46 To: sth...@nethelp.no Cc: Maxim Khitrov; Current FreeBSD; Mailinglists FreeBSD Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? On Mon, Jul 21, 2014 at 8:56 AM, sth...@nethelp.no wrote: Also, the openbsd stack has some essential features missing in freebsd, like mpls and md5 auth for bgp sessions. I use MD5 auth for BGP sessions every day (and have been doing so for several releases). One could definitely wish for better integration - having to specify MD5 key both in /etc/ipsec.conf and in the Quagga bgpd config is not nice. But it works. As far as I know you can only send out correctly authed stuff but not validate incoming. Has that changed? Have a look at tcp_signature_verify(), called from tcp_input.c. Added in r221023, see http://svnweb.freebsd.org/base/head/sys/netinet/tcp_input.c?view=log Steinar Haug, Nethelp consulting, sth...@nethelp.no -- Revision 221023 - (view) (download) (annotate) - [select for diffs] Modified Mon Apr 25 17:13:40 2011 UTC (3 years, 2 months ago) by attilio File length: 106717 byte(s) Diff to previous 220560 Add the possibility to verify MD5 hash of incoming TCP packets. As long as this is a costy function, even when compiled in (along with the option TCP_SIGNATURE), it can be disabled via the net.inet.tcp.signature_verify_input sysctl. Sponsored by: Sandvine Incorporated Reviewed by:emaste, bz MFC after: 2 weeks I stand corrected. Excellent news ( for me, that is) :) Best regards Andeas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current- unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Hi Julian, On 21 Jul 2014, at 05:15, Julian Elischer jul...@freebsd.org wrote: Most people I talk to just use ipfw and couldn't care whether pf lives or dies. They have simple requirements and almost any filter would suffice. I haven't found anything I'd want to use pf for that ipfw doesn't allow me to do. There are things pf does that ipfw doesn't... I just never want them.. this is quite insightful. The gist of this discussion and the apparent lack of upgrades to pf(4) seem to indicate that: (a) other packet filters do the required jobs equally or better or performance doesn't matter at all. (b) for more progressive setups and requirements, FreeBSD servers may as well be complemented with commercial firewalls, hand-rolled or non-FreeBSD solutions Is that somewhat accurate, or is there more to the story? Cheers, Franco ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 2014-07-21 09:57, bycn82 wrote: There is no doubt that PF is a really good firewall, But we should noticed that there is an ipfw which is originally from FreeBSD while PF is from OpenBSD. If there is a requirement that PF can meet but ipfw cannot, then I think it is better to improve the ipfw. But if you just like the PF style, then I think choose OpenBSD is the better solution. Actually OpenBSD is another really good operating system. Like myself, I like CentOS and ipfw, so no choice :) The only thing I've really found lacking in IPFW is the NAT implementation. Specifically, when trying to do port-forwarding. All of the rules have to go in the single 'ipfw nat' rule, and it makes it cumbersome to manage. -- Allan Jude signature.asc Description: OpenPGP digital signature
NPF (was Re: Future of pf / firewall in FreeBSD ? - does it have one ?)
FWIW, and while I still wonder why we need three packet filters … There is yet another firewall implementation in NetBSD: http://www.netbsd.org/~rmind/npf/ It seems to be more portable, it is thought with SMP-friendliness in mind and according to a EuroBSDCon talk ports for FreeBSD and Illumos were being considered. Good to have more options … I think. Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: Future of pf / firewall in FreeBSD ? - does it have one ?
i thought the nat in ipfw is as elegant as in iptables :) but it is good to know that because different opinion actually is a chance to improve. and why not share with us why the ipfw nat is cumbersome or how to be not cumbersome. -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- curr...@freebsd.org] On Behalf Of Allan Jude Sent: 22 July, 2014 7:13 To: freebsd-current@freebsd.org Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? On 2014-07-21 09:57, bycn82 wrote: There is no doubt that PF is a really good firewall, But we should noticed that there is an ipfw which is originally from FreeBSD while PF is from OpenBSD. If there is a requirement that PF can meet but ipfw cannot, then I think it is better to improve the ipfw. But if you just like the PF style, then I think choose OpenBSD is the better solution. Actually OpenBSD is another really good operating system. Like myself, I like CentOS and ipfw, so no choice :) The only thing I've really found lacking in IPFW is the NAT implementation. Specifically, when trying to do port-forwarding. All of the rules have to go in the single 'ipfw nat' rule, and it makes it cumbersome to manage. -- Allan Jude ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
all of that is true, but you are missing the point. Having two versions of pf on the bsd's at the user level, is a bad thing. It confuses people, which puts them off. Its a classic case of divide an conquer for other platforms. I really like the idea of the openpf version, that has been mentioned in this thread. It would be awesome if it ended up as a supported linux thing as well, so the world could be rid of iptables. However i guess thats just an unrealistic dream On 19 July 2014 09:32, Stephen Hurd sh...@sasktel.net wrote: krad wrote: that is true and I have not problem using man pages, however thats not the way most of the world work and search engines arent exactly new either. We should be trying to engage more people not less, and part of that is reaching out. One of FreeBSD's historic strengths has been the handbook and generally good quality documentation. There is no way that the FreeBSD project can ensure that all Google results for everyone in the world are FreeBSD related good documentation, but it can ensure that the documentation included with FreeBSD is accurate and usable, and it can ensure that the FreeBSD documentation is available via the internet. Aside from blindly following whatever generates the most Google results (an obviously broken solution), what exactly can the FreeBSD project do to ensure that when someone Googles a problem they will end up with a correct FreeBSD solution? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Sun, Jul 20, 2014 at 12:18:54PM +0100, krad wrote: all of that is true, but you are missing the point. Having two versions of pf on the bsd's at the user level, is a bad thing. It confuses people, which puts them off. Its a classic case of divide an conquer for other platforms. I really like the idea of the openpf version, that has been mentioned in this thread. It would be awesome if it ended up as a supported linux thing as well, so the world could be rid of iptables. However i guess thats just an unrealistic dream And you don't seem to get the point that _someone_ has to do the work. No one has stepped up so far, so nothing is going to change. pgpUUxw9Z8IbB.pgp Description: PGP signature
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Sun, Jul 20, 2014 at 8:39 AM, Lars Engels lars.eng...@0x20.net wrote: On Sun, Jul 20, 2014 at 12:18:54PM +0100, krad wrote: all of that is true, but you are missing the point. Having two versions of pf on the bsd's at the user level, is a bad thing. It confuses people, which puts them off. Its a classic case of divide an conquer for other platforms. I really like the idea of the openpf version, that has been mentioned in this thread. It would be awesome if it ended up as a supported linux thing as well, so the world could be rid of iptables. However i guess thats just an unrealistic dream And you don't seem to get the point that _someone_ has to do the work. No one has stepped up so far, so nothing is going to change. Gleb believes that the majority of FreeBSD users don't want the updated syntax, among other changes, from the more recent pf versions. Developers who share his opinion are not going to volunteer to do the work. This discussion is about showing this belief to be wrong, which is the first step in the process. In my opinion, the way forward is to forget (at least temporarily) the SMP changes, bring pf in sync with OpenBSD, put a policy in place to follow their releases as closely as possible, and then try to reintroduce all the SMP work. I think the latter has to be done upstream, otherwise it'll always be a story of diverging codebases. Furthermore, if FreeBSD developers were willing to spend some time improving pf performance on OpenBSD, then Henning and other OpenBSD developers might be more receptive to changes that make the porting process easier. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Sun, Jul 20, 2014 at 10:15:36AM -0400, Maxim Khitrov wrote: On Sun, Jul 20, 2014 at 8:39 AM, Lars Engels lars.eng...@0x20.net wrote: On Sun, Jul 20, 2014 at 12:18:54PM +0100, krad wrote: all of that is true, but you are missing the point. Having two versions of pf on the bsd's at the user level, is a bad thing. It confuses people, which puts them off. Its a classic case of divide an conquer for other platforms. I really like the idea of the openpf version, that has been mentioned in this thread. It would be awesome if it ended up as a supported linux thing as well, so the world could be rid of iptables. However i guess thats just an unrealistic dream And you don't seem to get the point that _someone_ has to do the work. No one has stepped up so far, so nothing is going to change. Gleb believes that the majority of FreeBSD users don't want the updated syntax, among other changes, from the more recent pf versions. Developers who share his opinion are not going to volunteer to do the work. This discussion is about showing this belief to be wrong, which is the first step in the process. In my opinion, the way forward is to forget (at least temporarily) the SMP changes, bring pf in sync with OpenBSD, put a policy in place to follow their releases as closely as possible, and then try to reintroduce all the SMP work. I think the latter has to be done upstream, otherwise it'll always be a story of diverging codebases. Furthermore, if FreeBSD developers were willing to spend some time improving pf performance on OpenBSD, then Henning and other OpenBSD developers might be more receptive to changes that make the porting process easier. smp is not the only change we did, if you forget about it you will also get into other co plication to sync from openbsd Bapt pgpOKWmBlTB9y.pgp Description: PGP signature
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 7/19/2014 at 9:36 PM Darren Pilgrim wrote: |On 7/18/2014 6:51 AM, Franco Fichtner wrote: | [snip] | | |All because over half a decade ago some folks got all butthurt over a |config file format change. = I'm juggling two formats for specifying NIC configurations in rc.conf, one on a 8.4 server and another on some 10.0 servers. I've also been through pf.conf syntax changes in the past, and I expect to be subject to pf.con syntax changes in the future. Did I have to do some extra work to accomodate those changes? Yes. Was it worth the effort? Absolutely. Not only am I handling the handling of two NIC configuration syntaxes OK, I look forward to when I can bring the 8.4 server up to 10.x for, among other things, imo the better syntax of the networking configuration in 10.x. imho, the root problem here is that an effort to implement a single feature improvement (multi-threading) has caused the FreeBSD version of pf to apparently reach a near-unmaintainable position in the FreeBSD community because improvements from OpenBSD can no longer be ported over easily. FreeBSD's pf has been put in a virtual isolation chamber due to the multi-threaded enhancement. Was it worth it? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 20 Jul 2014, at 15:39, Mike. the.li...@mgm51.com wrote: imho, the root problem here is that an effort to implement a single feature improvement (multi-threading) has caused the FreeBSD version of pf to apparently reach a near-unmaintainable position in the FreeBSD community because improvements from OpenBSD can no longer be ported over easily. FreeBSD's pf has been put in a virtual isolation chamber due to the multi-threaded enhancement. Was it worth it? Yes. This happened *three times* in BSD land now. How much more proof does it take to make that clear? FWIW, I'm still volunteering, but I think the direction this discussion is going is that there is no clear direction, which makes this a tad less effective than it could be. ;) Cheers, Franco ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 7/20/2014 at 5:38 PM Franco Fichtner wrote: |On 20 Jul 2014, at 15:39, Mike. the.li...@mgm51.com wrote: | | imho, the root problem here is that an effort to implement a single | feature improvement (multi-threading) has caused the FreeBSD version | of pf to apparently reach a near-unmaintainable position in the | FreeBSD community because improvements from OpenBSD can no longer be | ported over easily. FreeBSD's pf has been put in a virtual | isolation chamber due to the multi-threaded enhancement. | | Was it worth it? | |Yes. This happened *three times* in BSD land now. How much more |proof does it take to make that clear? |[snip] = In this instance, more proof would consist of pf development not wallowing in inactivity. imo, tactical changes were implemented in pf without the strategic negative consequences affecting the decision process guiding the implementation of those tactical features.And that's backwards. Strategies direct tactics, not vice versa. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Sun, 20 Jul 2014 10:15:36 -0400 Maxim Khitrov m...@mxcrypt.com wrote: On Sun, Jul 20, 2014 at 8:39 AM, Lars Engels lars.eng...@0x20.net wrote: On Sun, Jul 20, 2014 at 12:18:54PM +0100, krad wrote: all of that is true, but you are missing the point. Having two versions of pf on the bsd's at the user level, is a bad thing. It confuses people, which puts them off. Its a classic case of divide an conquer for other platforms. I really like the idea of the openpf version, that has been mentioned in this thread. It would be awesome if it ended up as a supported linux thing as well, so the world could be rid of iptables. However i guess thats just an unrealistic dream And you don't seem to get the point that _someone_ has to do the work. No one has stepped up so far, so nothing is going to change. Gleb believes that the majority of FreeBSD users don't want the updated syntax, among other changes, from the more recent pf versions. Developers who share his opinion are not going to volunteer to do the work. This discussion is about showing this belief to be wrong, which is the first step in the process. In my opinion, the way forward is to forget (at least temporarily) the SMP changes, bring pf in sync with OpenBSD, put a policy in place to follow their releases as closely as possible, and then try to reintroduce all the SMP work. I think the latter has to be done upstream, otherwise it'll always be a story of diverging codebases. Furthermore, if FreeBSD developers were willing to spend some time improving pf performance on OpenBSD, then Henning and other OpenBSD developers might be more receptive to changes that make the porting process easier. I am one person whose opinion Gleb got completely right - I could not care less about new syntax nor about how close or how far are we from OpenBSD, as long as pf works for my purposes and it does. This far into the thread and somebody has yet to provide a comprehensive list of the benefits that we allegedly miss, or to come up with the real benchmark result to substantiate the performance claims. Focusing on disproving anything Gleb might be believing in on the matter, while an interesting undertaking, does nothing to give you new pf you supposedly want. Doing the work and bringing it all the way to will completeness for commit - does. It was stated repeatedly by multiple people that FreeBSD's network stack is way too different from OpenBSD, we support features OpenBSD doesn't and vice versa, vimage is a good example, which throws a giant wrench into the plan of following OpenBSD 'as closely as possible', even as the expense of throwing away all of the SMP work done in pf to date. -- Alexander Kabaev signature.asc Description: PGP signature
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
krad kra...@gmail.com writes: Hi, I really like the idea of the openpf version, that has been mentioned in this thread. It would be nice but as it's been written in this thread, Open Free internals are quite different beasts, goals are different on both platforms, so I doubt OpenPF will exist in the future. It would be awesome if it ended up as a supported linux thing as well, so the world could be rid of iptables. Linux world will get rid of iptables one of these days, nftables inclusion in mainline is a clear signal. I don't really like linux firewalling engines but projects like OpenWRT and Luci hide the command line hell in most cases, so I'm slowly retiring FreeBSD/pf handcrafted appliances in favor of OpenWRT boxes. Éric Masson -- Bonjour je sais qu il existe un prog pour faire des cartes bancaires puis je l avoir par mail pas pour en fabriquer mais par curiosite merci a tous -+- LM In GNU : La cléf pour fabriquer un neuneu enfin dévoilée -+- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Sun, 20 Jul 2014, Lars Engels wrote: On Sun, Jul 20, 2014 at 12:18:54PM +0100, krad wrote: all of that is true, but you are missing the point. Having two versions of pf on the bsd's at the user level, is a bad thing. It confuses people, which puts them off. Its a classic case of divide an conquer for other platforms. I really like the idea of the openpf version, that has been mentioned in this thread. It would be awesome if it ended up as a supported linux thing as well, so the world could be rid of iptables. However i guess thats just an unrealistic dream And you don't seem to get the point that _someone_ has to do the work. No one has stepped up so far, so nothing is going to change. No one with authority has yet said that If an updated pf were available, would be welcomed. Rather they have said An updated pf would not be suitable, as it would be incompatible with existing configuration files. If the latter is indeed the case, there is little incentive for anyone to go to the effort of porting the newer pf. After all, the reward for the work is chiefly in glory, and if there is to be no glory, the work is unlikely to be done. I do not have a horse in this race. Daniel Feenberg NBER ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Jul 20, 2014, at 11:35 AM, Daniel Feenberg feenb...@nber.org wrote: Rather they have said An updated pf would not be suitable, as it would be incompatible with existing configuration files. A major FreeBSD version increment is allowed to break that level of backwards compatibility. Nothing prevents this from being incorporated into 11.x. The only real concern would be removing existing core functionality as part of the update. For that you want to provide at least one major release cycle for people up migrate. Comparing pf on my current OpenBSD machines vs. the FreeBSD 10.x pf, that doesn't seem to be an issue. --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Hi! And you don't seem to get the point that _someone_ has to do the work. No one has stepped up so far, so nothing is going to change. Franco Fichtner said he's interested in doing it. He probably needs funding. No one with authority has yet said that If an updated pf were available, would be welcomed. Which person or group would you view as authority in this case ? -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
krad wrote: all of that is true, but you are missing the point. Having two versions of pf on the bsd's at the user level, is a bad thing. It confuses people, which puts them off. Its a classic case of divide an conquer for other platforms. I really like the idea of the openpf version, that has been mentioned in this thread. It would be awesome if it ended up as a supported linux thing as well, so the world could be rid of iptables. However i guess thats just an unrealistic dream No, the point was that matching OpenBSDs pf syntax for the sake of the Google results isn't a valid reason to change it. I'm not saying there aren't any valid reasons, just that useless search results isn't one of them. As for my opinion of the rule format changing, I'm fine with it as long as it happens on a major version release (ie: 11.0) and is documented. If I want to use the old pf, I'll use an old FreeBSD. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Noone needs to say you can do X. You can just fork freebsd in whatever form you want, update to the latest github and work to eventually get it included. Or you could treat it as an entirely external-from-system plugin module that you compile up - the packet filter hooks API lets you do this relatively nicely nowdays. There's multiple ways to do this. No-one needs to ask permission. Someone just has to do it. So if you want to do it, say so, and please feel free to canvas for donations / funding / whatever you need to keep up whatever you need to get it done. You don't need permission. Don't worry about how to get it into the tree when you're done. Just do it. -a On 20 July 2014 15:26, Daniel Feenberg feenb...@nber.org wrote: On Sun, 20 Jul 2014, Kurt Jaeger wrote: Hi! And you don't seem to get the point that _someone_ has to do the work. No one has stepped up so far, so nothing is going to change. Franco Fichtner said he's interested in doing it. He probably needs funding. No one with authority has yet said that If an updated pf were available, would be welcomed. Which person or group would you view as authority in this case ? I am not privy to the inner workings of the project, but surely a decision of this importance would come to the attention of the core team, who are listed at: http://www.freebsd.org/administration.html#t-core A port of OpenBSD PF may be quite impractical or undesirable- I have no idea. However, if all potential contributions are viewed as criticism to be refuted, it will damage the ability of the project to attract contributors. Rather than telling a potential contributor that their efforts will never be included in the official distribution it would be more supportive of the project to say that a port of PF would be welcome as a port, but might have difficulty displacing current offering. That doesn't promise anything, but encourages involvement, if indeed involvement is desired. Daniel Feenberg -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Sun, Jul 20, 2014 at 7:41 PM, Alexander Kabaev kab...@gmail.com wrote: On Sun, 20 Jul 2014 10:15:36 -0400 Maxim Khitrov m...@mxcrypt.com wrote: On Sun, Jul 20, 2014 at 8:39 AM, Lars Engels lars.eng...@0x20.net wrote: On Sun, Jul 20, 2014 at 12:18:54PM +0100, krad wrote: all of that is true, but you are missing the point. Having two versions of pf on the bsd's at the user level, is a bad thing. It confuses people, which puts them off. Its a classic case of divide an conquer for other platforms. I really like the idea of the openpf version, that has been mentioned in this thread. It would be awesome if it ended up as a supported linux thing as well, so the world could be rid of iptables. However i guess thats just an unrealistic dream And you don't seem to get the point that _someone_ has to do the work. No one has stepped up so far, so nothing is going to change. Gleb believes that the majority of FreeBSD users don't want the updated syntax, among other changes, from the more recent pf versions. Developers who share his opinion are not going to volunteer to do the work. This discussion is about showing this belief to be wrong, which is the first step in the process. In my opinion, the way forward is to forget (at least temporarily) the SMP changes, bring pf in sync with OpenBSD, put a policy in place to follow their releases as closely as possible, and then try to reintroduce all the SMP work. I think the latter has to be done upstream, otherwise it'll always be a story of diverging codebases. Furthermore, if FreeBSD developers were willing to spend some time improving pf performance on OpenBSD, then Henning and other OpenBSD developers might be more receptive to changes that make the porting process easier. I am one person whose opinion Gleb got completely right - I could not care less about new syntax nor about how close or how far are we from OpenBSD, as long as pf works for my purposes and it does. This far into the thread and somebody has yet to provide a comprehensive list of the benefits that we allegedly miss, or to come up with the real benchmark result to substantiate the performance claims. Focusing on disproving anything Gleb might be believing in on the matter, while an interesting undertaking, does nothing to give you new pf you supposedly want. Doing the work and bringing it all the way to will completeness for commit - does. It was stated repeatedly by multiple people that FreeBSD's network stack is way too different from OpenBSD, we support features OpenBSD doesn't and vice versa, vimage is a good example, which throws a giant wrench into the plan of following OpenBSD 'as closely as possible', even as the expense of throwing away all of the SMP work done in pf to date. I like vimage, don't get me wrong, but it also seems to have lost traction. If vimage is the only thing holding a pf import back there ought to be some discussion about which is a priority. Also, the openbsd stack has some essential features missing in freebsd, like mpls and md5 auth for bgp sessions. /A ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Sun, 20 Jul 2014, Kurt Jaeger wrote: Hi! And you don't seem to get the point that _someone_ has to do the work. No one has stepped up so far, so nothing is going to change. Franco Fichtner said he's interested in doing it. He probably needs funding. No one with authority has yet said that If an updated pf were available, would be welcomed. Which person or group would you view as authority in this case ? I am not privy to the inner workings of the project, but surely a decision of this importance would come to the attention of the core team, who are listed at: http://www.freebsd.org/administration.html#t-core A port of OpenBSD PF may be quite impractical or undesirable- I have no idea. However, if all potential contributions are viewed as criticism to be refuted, it will damage the ability of the project to attract contributors. Rather than telling a potential contributor that their efforts will never be included in the official distribution it would be more supportive of the project to say that a port of PF would be welcome as a port, but might have difficulty displacing current offering. That doesn't promise anything, but encourages involvement, if indeed involvement is desired. Daniel Feenberg -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 7/20/14, 12:36 PM, Darren Pilgrim wrote: The vast majority of people don't know pf is outdated and broken on FreeBSD because they don't know what they're missing and likely aren't using IPv6 yet. s/IPv6/pf/ Most people I talk to just use ipfw and couldn't care whether pf lives or dies. They have simple requirements and almost any filter would suffice. I haven't found anything I'd want to use pf for that ipfw doesn't allow me to do. There are things pf does that ipfw doesn't... I just never want them.. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 7/21/14, 7:27 AM, Andreas Nilsson wrote: On Sun, Jul 20, 2014 at 7:41 PM, Alexander Kabaev kab...@gmail.com wrote: On Sun, 20 Jul 2014 10:15:36 -0400 Maxim Khitrov m...@mxcrypt.com wrote: On Sun, Jul 20, 2014 at 8:39 AM, Lars Engels lars.eng...@0x20.net wrote: On Sun, Jul 20, 2014 at 12:18:54PM +0100, krad wrote: all of that is true, but you are missing the point. Having two versions of pf on the bsd's at the user level, is a bad thing. It confuses people, which puts them off. Its a classic case of divide an conquer for other platforms. I really like the idea of the openpf version, that has been mentioned in this thread. It would be awesome if it ended up as a supported linux thing as well, so the world could be rid of iptables. However i guess thats just an unrealistic dream And you don't seem to get the point that _someone_ has to do the work. No one has stepped up so far, so nothing is going to change. Gleb believes that the majority of FreeBSD users don't want the updated syntax, among other changes, from the more recent pf versions. Developers who share his opinion are not going to volunteer to do the work. This discussion is about showing this belief to be wrong, which is the first step in the process. In my opinion, the way forward is to forget (at least temporarily) the SMP changes, bring pf in sync with OpenBSD, put a policy in place to follow their releases as closely as possible, and then try to reintroduce all the SMP work. I think the latter has to be done upstream, otherwise it'll always be a story of diverging codebases. Furthermore, if FreeBSD developers were willing to spend some time improving pf performance on OpenBSD, then Henning and other OpenBSD developers might be more receptive to changes that make the porting process easier. I am one person whose opinion Gleb got completely right - I could not care less about new syntax nor about how close or how far are we from OpenBSD, as long as pf works for my purposes and it does. This far into the thread and somebody has yet to provide a comprehensive list of the benefits that we allegedly miss, or to come up with the real benchmark result to substantiate the performance claims. Focusing on disproving anything Gleb might be believing in on the matter, while an interesting undertaking, does nothing to give you new pf you supposedly want. Doing the work and bringing it all the way to will completeness for commit - does. It was stated repeatedly by multiple people that FreeBSD's network stack is way too different from OpenBSD, we support features OpenBSD doesn't and vice versa, vimage is a good example, which throws a giant wrench into the plan of following OpenBSD 'as closely as possible', even as the expense of throwing away all of the SMP work done in pf to date. I like vimage, don't get me wrong, but it also seems to have lost traction. If vimage is the only thing holding a pf import back there ought to be some discussion about which is a priority. As one involved with Vimage, I get feedback all the time that lets me know it's in really heavy use in some pretty interesting commercial situations. It HAS lst some traction in terms of added work, but that's because it's solid enough for people to use. In the situations where it's being used, it's a game changer and rhe conversation goes something like: hey vimage and pf don't work together.. guess that makes the firewall decision easy.. use ipfw Also, the openbsd stack has some essential features missing in freebsd, like mpls and md5 auth for bgp sessions. /A ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Mon, Jul 21, 2014 at 5:24 AM, Julian Elischer jul...@freebsd.org wrote: On 7/21/14, 7:27 AM, Andreas Nilsson wrote: On Sun, Jul 20, 2014 at 7:41 PM, Alexander Kabaev kab...@gmail.com wrote: On Sun, 20 Jul 2014 10:15:36 -0400 Maxim Khitrov m...@mxcrypt.com wrote: On Sun, Jul 20, 2014 at 8:39 AM, Lars Engels lars.eng...@0x20.net wrote: On Sun, Jul 20, 2014 at 12:18:54PM +0100, krad wrote: all of that is true, but you are missing the point. Having two versions of pf on the bsd's at the user level, is a bad thing. It confuses people, which puts them off. Its a classic case of divide an conquer for other platforms. I really like the idea of the openpf version, that has been mentioned in this thread. It would be awesome if it ended up as a supported linux thing as well, so the world could be rid of iptables. However i guess thats just an unrealistic dream And you don't seem to get the point that _someone_ has to do the work. No one has stepped up so far, so nothing is going to change. Gleb believes that the majority of FreeBSD users don't want the updated syntax, among other changes, from the more recent pf versions. Developers who share his opinion are not going to volunteer to do the work. This discussion is about showing this belief to be wrong, which is the first step in the process. In my opinion, the way forward is to forget (at least temporarily) the SMP changes, bring pf in sync with OpenBSD, put a policy in place to follow their releases as closely as possible, and then try to reintroduce all the SMP work. I think the latter has to be done upstream, otherwise it'll always be a story of diverging codebases. Furthermore, if FreeBSD developers were willing to spend some time improving pf performance on OpenBSD, then Henning and other OpenBSD developers might be more receptive to changes that make the porting process easier. I am one person whose opinion Gleb got completely right - I could not care less about new syntax nor about how close or how far are we from OpenBSD, as long as pf works for my purposes and it does. This far into the thread and somebody has yet to provide a comprehensive list of the benefits that we allegedly miss, or to come up with the real benchmark result to substantiate the performance claims. Focusing on disproving anything Gleb might be believing in on the matter, while an interesting undertaking, does nothing to give you new pf you supposedly want. Doing the work and bringing it all the way to will completeness for commit - does. It was stated repeatedly by multiple people that FreeBSD's network stack is way too different from OpenBSD, we support features OpenBSD doesn't and vice versa, vimage is a good example, which throws a giant wrench into the plan of following OpenBSD 'as closely as possible', even as the expense of throwing away all of the SMP work done in pf to date. I like vimage, don't get me wrong, but it also seems to have lost traction. If vimage is the only thing holding a pf import back there ought to be some discussion about which is a priority. As one involved with Vimage, I get feedback all the time that lets me know it's in really heavy use in some pretty interesting commercial situations. It HAS lst some traction in terms of added work, but that's because it's solid enough for people to use. In the situations where it's being used, it's a game changer and rhe conversation goes something like: hey vimage and pf don't work together.. guess that makes the firewall decision easy.. use ipfw Good to know! Also, the openbsd stack has some essential features missing in freebsd, like mpls and md5 auth for bgp sessions. /A ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Mon, Jul 21, 2014 at 7:41 AM, sth...@nethelp.no wrote: Also, the openbsd stack has some essential features missing in freebsd, like mpls and md5 auth for bgp sessions. I use MD5 auth for BGP sessions every day (and have been doing so for several releases). One could definitely wish for better integration - having to specify MD5 key both in /etc/ipsec.conf and in the Quagga bgpd config is not nice. But it works. As far as I know you can only send out correctly authed stuff but not validate incoming. Has that changed? /Andreas MPLS would be nice - but is not a high priority. That's what I use Juniper and Cisco routers for. For MPLS to be of any use I'd also need a working IS-IS implementation, and I believe Quagga isn't quite there yet. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Also, the openbsd stack has some essential features missing in freebsd, like mpls and md5 auth for bgp sessions. I use MD5 auth for BGP sessions every day (and have been doing so for several releases). One could definitely wish for better integration - having to specify MD5 key both in /etc/ipsec.conf and in the Quagga bgpd config is not nice. But it works. MPLS would be nice - but is not a high priority. That's what I use Juniper and Cisco routers for. For MPLS to be of any use I'd also need a working IS-IS implementation, and I believe Quagga isn't quite there yet. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
krad wrote: that is true and I have not problem using man pages, however thats not the way most of the world work and search engines arent exactly new either. We should be trying to engage more people not less, and part of that is reaching out. One of FreeBSD's historic strengths has been the handbook and generally good quality documentation. There is no way that the FreeBSD project can ensure that all Google results for everyone in the world are FreeBSD related good documentation, but it can ensure that the documentation included with FreeBSD is accurate and usable, and it can ensure that the FreeBSD documentation is available via the internet. Aside from blindly following whatever generates the most Google results (an obviously broken solution), what exactly can the FreeBSD project do to ensure that when someone Googles a problem they will end up with a correct FreeBSD solution? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Sat, Jul 19, 2014 at 4:40 AM, Darren Pilgrim list_free...@bluerosetech.com wrote: On 7/18/2014 4:06 AM, Gleb Smirnoff wrote: K b) We are a major release away from OpenBSD (5.6 coming soon) - is K following OpenBSD's pf the past? - should it be? Following OpenBSD on features would be cool, but no bulk imports would be made again. Bulk imports produce bad quality of port, and also pf in OpenBSD has no multi thread support. I would much rather have a slower pf that actually supports modern networking than a faster one I can't use due to showstopper flaws and missing features. So would I. Not that we use pf, but anyway. There is currently no viable firewall module for FreeBSD if you want to do things like route IPv6. Isn't that possible with ipfw? Perhaps the pf guys in OpenBSD could be convinced to start openpf and have porting layer as in openzfs. Best regards Andreas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Fri, Jul 18, 2014 at 03:22:18PM -0400, Allan Jude wrote: On 2014-07-18 15:07, Adrian Chadd wrote: On 18 July 2014 07:34, krad kra...@gmail.com wrote: that is true and I have not problem using man pages, however thats not the way most of the world work and search engines arent exactly new either. We should be trying to engage more people not less, and part of that is reaching out. Then do the port and maintain it. The problem isn't the desire to keep things up to date, it's a lack of people who want that _and_ are willing/able to do it _and_ are funded somehow. So, please step up! We'll all love you for it. -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org At vBSDCon Bapt@ volunteered to port the newer pf back to FreeBSD, after spending some hours driving with Henning. I tried and broke pf for month and my changes have been reverted, this is not as simple as it looks like, our code as diverge a lot in some part and we do support things that openbsd does not (vimage). Sync features requires us to be very careful, my priorities went elsewhere since that time, so now I will probably only focus on bringing features I care about, and not the entirely new pf. So no do not count me as volunteer to maintain pf, I ll probably do some work but not a full sync. Bapt pgptS4Q5WDmxQ.pgp Description: PGP signature
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Jul 19, 2014, at 3:35, Andreas Nilsson andrn...@gmail.com wrote: On Sat, Jul 19, 2014 at 4:40 AM, Darren Pilgrim list_free...@bluerosetech.com wrote: On 7/18/2014 4:06 AM, Gleb Smirnoff wrote: K b) We are a major release away from OpenBSD (5.6 coming soon) - is K following OpenBSD's pf the past? - should it be? Following OpenBSD on features would be cool, but no bulk imports would be made again. Bulk imports produce bad quality of port, and also pf in OpenBSD has no multi thread support. I would much rather have a slower pf that actually supports modern networking than a faster one I can't use due to showstopper flaws and missing features. So would I. Not that we use pf, but anyway. There is currently no viable firewall module for FreeBSD if you want to do things like route IPv6. Isn't that possible with ipfw? Perhaps the pf guys in OpenBSD could be convinced to start openpf and have porting layer as in openzfs. I do not know ipfw IPv6 limitations, but the Wikipedia article says: * IPv6 support (with several limitations) Choice is nice, but I would like to see the project promote one firewall to users. My coworkers long ago jumped ship from ipfw to pf and I know regret that decision due to the IPv6 bugs. At this point it's too hard to migrate all the servers off of pf. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Sat, Jul 19, 2014 at 6:50 AM, Mark Felder f...@freebsd.org wrote: On Jul 19, 2014, at 3:35, Andreas Nilsson andrn...@gmail.com wrote: On Sat, Jul 19, 2014 at 4:40 AM, Darren Pilgrim list_free...@bluerosetech.com wrote: On 7/18/2014 4:06 AM, Gleb Smirnoff wrote: K b) We are a major release away from OpenBSD (5.6 coming soon) - is K following OpenBSD's pf the past? - should it be? Following OpenBSD on features would be cool, but no bulk imports would be made again. Bulk imports produce bad quality of port, and also pf in OpenBSD has no multi thread support. I would much rather have a slower pf that actually supports modern networking than a faster one I can't use due to showstopper flaws and missing features. So would I. Not that we use pf, but anyway. There is currently no viable firewall module for FreeBSD if you want to do things like route IPv6. Isn't that possible with ipfw? Perhaps the pf guys in OpenBSD could be convinced to start openpf and have porting layer as in openzfs. I do not know ipfw IPv6 limitations, but the Wikipedia article says: * IPv6 support (with several limitations) Choice is nice, but I would like to see the project promote one firewall to users. My coworkers long ago jumped ship from ipfw to pf and I know regret that decision due to the IPv6 bugs. At this point it's too hard to migrate all the servers off of pf. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org I believe that this is obsolete, at least with 10. It certainly used to be the case in older versions. I suspect the improved ipfw is now in 9.3 and perhaps even 8.4, but I can't swear to it. I do know that the 10.0 version broke several of my firewall rules which would have made back-porting to older versions unacceptable but I believe that this is no longer the case. Some IPv6 specific keywords had been eliminated, but I think that they are all back in place, now. No longer required, but there for compatibility. The last feature I am aware of that lacked ipv6 support was tables. If any more exist, they are subtle and I have not hit hem to this point. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Saturday 19 July 2014 13:06:52 Baptiste Daroussin wrote: On Fri, Jul 18, 2014 at 03:22:18PM -0400, Allan Jude wrote: On 2014-07-18 15:07, Adrian Chadd wrote: On 18 July 2014 07:34, krad kra...@gmail.com wrote: that is true and I have not problem using man pages, however thats not the way most of the world work and search engines arent exactly new either. We should be trying to engage more people not less, and part of that is reaching out. Then do the port and maintain it. The problem isn't the desire to keep things up to date, it's a lack of people who want that _and_ are willing/able to do it _and_ are funded somehow. So, please step up! We'll all love you for it. -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org At vBSDCon Bapt@ volunteered to port the newer pf back to FreeBSD, after spending some hours driving with Henning. I tried and broke pf for month and my changes have been reverted, this is not as simple as it looks like, our code as diverge a lot in some part and we do support things that openbsd does not (vimage). Sync features requires us to be very careful, my priorities went elsewhere since that time, so now I will probably only focus on bringing features I care about, and not the entirely new pf. So no do not count me as volunteer to maintain pf, I ll probably do some work but not a full sync. If anyone is looking for a really useful chunk to work on, please go back over the pf history in openbsd and find where they added ipv6 fragment support. It was fairly well contained and didn't appear to be a big deal to port. They did do something with mbuf tags that I'm suspicious of though. IPv6 fragments are the biggest pain point we have on the freebsd.org cluster - yes, we use pf and IPv6 extensively, but dns with ipv6 involved is really painful without fragment support. We sort-of work around it by using dedicated IPv6 address that has nothing but the dns resolver clients and allow ipv6 fragments to it. Its not ideal but it gets over the worst problems. The other thing we had to do for usability is stop state tracking for udp dns - the sheer update rate was causing collisions and state drops / resets of other connections to the point of being really hard to use. Those two tweaks - stopping heavy dns use from thrashing the state tables, and having a safe place to send fragments makes it quite usable for freebsd.org. But, lack of ipv6 fragment processing still causes ongoing pain. That's our #1 wish list item for the cluster. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 signature.asc Description: This is a digitally signed message part.
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 7/18/2014 6:51 AM, Franco Fichtner wrote: c) We never got the new syntax from OpenBSD 4.7's pf - at the time a long discussion on the pf-mailing list flamed the new syntax saying it would cause FreeBSD administrators too much headache. Today on the list it seems everyone wants it - so would we rather stay on a dead branch than keep up with the main stream? I'd say many people are comfortable with an old state of pf (silent majority), but that shouldn't keep us from catching up with newer features (and of course bugfixes). Never mistake silence for consent. The vast majority of people don't know pf is outdated and broken on FreeBSD because they don't know what they're missing and likely aren't using IPv6 yet. The moment you turn on IPv6 and restart a validating unbound, you run full-speed into pf's broken behaviour. Make an EDNS0-enabled query for a signed zone and you'll get a fragmented UDP packet that will never make it through unless you tell pf to allow all fragments unconditionally. They'll simply think something is wrong with unbound, turn off EDNS0 and/or validation, hurt peformance and/or security in the process, and never realize their firewall is doing literally the worst possible thing it could do. All because over half a decade ago some folks got all butthurt over a config file format change. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 19 July 2014 21:36, Darren Pilgrim list_free...@bluerosetech.com wrote: On 7/18/2014 6:51 AM, Franco Fichtner wrote: c) We never got the new syntax from OpenBSD 4.7's pf - at the time a long discussion on the pf-mailing list flamed the new syntax saying it would cause FreeBSD administrators too much headache. Today on the list it seems everyone wants it - so would we rather stay on a dead branch than keep up with the main stream? I'd say many people are comfortable with an old state of pf (silent majority), but that shouldn't keep us from catching up with newer features (and of course bugfixes). Never mistake silence for consent. The vast majority of people don't know pf is outdated and broken on FreeBSD because they don't know what they're missing and likely aren't using IPv6 yet. The moment you turn on IPv6 and restart a validating unbound, you run full-speed into pf's broken behaviour. Make an EDNS0-enabled query for a signed zone and you'll get a fragmented UDP packet that will never make it through unless you tell pf to allow all fragments unconditionally. They'll simply think something is wrong with unbound, turn off EDNS0 and/or validation, hurt peformance and/or security in the process, and never realize their firewall is doing literally the worst possible thing it could do. All because over half a decade ago some folks got all butthurt over a config file format change. if someone wants to port the up to date pf and can fix whatever performance / parallelism issues creep up, then go for it. -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Kristian, On Thu, Jul 17, 2014 at 01:12:09AM +0200, Kristian K. Nielsen wrote: K a) First of all - are any actively developing pf in FreeBSD? No one right now. K b) We are a major release away from OpenBSD (5.6 coming soon) - is K following OpenBSD's pf the past? - should it be? Following OpenBSD on features would be cool, but no bulk imports would be made again. Bulk imports produce bad quality of port, and also pf in OpenBSD has no multi thread support. K c) We never got the new syntax from OpenBSD 4.7's pf - at the time a K long discussion on the pf-mailing list flamed the new syntax saying it K would cause FreeBSD administrators too much headache. Today on the list K it seems everyone wants it - so would we rather stay on a dead branch K than keep up with the main stream? The pf mailing list is about a dozen of active people. Yes, they are vocal on the new syntax. But there also exist a large number of common FreeBSD users who simply use pf w/o caring about syntax and reading pf mailing list. If we destroy the syntax compatibility a very large population of users would be hurt, for the sake of making a dozen happy. K d) Anyone working on bringing FreeBSD up to pf 5.6? - seem dead on the K pf-list. See b). K e) OpenBSD is retiring ALTQ entirely - any thoughts on that? K http://undeadly.org/cgi?action=articlesid=20140419151959 We have plan on retiring the interface queues entirely. So, interfaces would have only a transmit method. However, we could make it pluggable: a altq_transmit is plugged in place of standard transmit. This will keep ALTQ in system, but w/o any affect on the rest of the stack. Very much like the pfil(9) interface cleansed up the network stack from ipfw/ipfilter hooks. This needs developer power, however. K f) IPv6 support?- it seem to be more and more challenged in the current K version of pf in FreeBSD and I am (as well as others) introducing more K and more IPv6 in networks. K E.x. Bugs #179392, #172648, #130381, #127920 and more seriously #124933, K which is the bug on not handling IPv6 fragments which have been open K since 2008 and where the workaround is necessity to leave an completely K open hole in your firewall ruleset to allow all fragments. According to K comment in the bug, this have been long gone in OpenBSD. Yes. This hurts a lot of people and needs manpower to be solved. K g) Performance, can we live with pf-performance that compared to OpenBSD K is slower by a factor of 3 or 4, even after the multi-core support in K FreeBSD 10? K (Henning Brauer noted that in this talk at K http://tech.yandex.ru/events/yagosti/ruBSD/talks/1488/ (at 33:18 and K 36:53)) - credit/Jim Thompson I was there. Henning Brauer impudently called a lies a fact that was carefully measured and provided with enough details (CPU, NIC, testing technique, configuration), so that anyone can reproduce and check that [1]. In next 10 seconds Henning Brauer claimed that on a single core OpenBSD is faster by a factor of 3 or 4, providing absolutely no test data. Impudently crying Lies! achieving approving laughter from the audience is a politian way of discussion. Uncorroborated claims, where predictions vary by 33%, is also politian tool. Henning definitely could made a carreer. Scientific way of discussion is making an experiment, publishing results and experiment details, so that anyone can reproduce. P.S. Not speaking about who cares about single core performance today? K h) Bringing back patches from pfSense? Possible if they are useful and license permits. Again, manpower required. K And my most important question: K K * Should this or could this be a project for the foundation to either do K a summer project or funded project to bring this part of the OS up to date? First, we need a person, then we need funding. In late 2012, when I finished the pf-smp project, I was seeking for funding to continue. Couple negotiations failed. Now I lost the momentum on pf and switched to other tasks, so I am not available. [1] I mean the testing made by Olivier Cochard Labbé. https://twitter.com/ocochardlabbe/status/401349027960082432/photo/1 More details in mailing list archives, or you can request from Olivier. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
I would like to see an updated version of pf. I realize its a big job to port it though On 17 July 2014 00:12, Kristian K. Nielsen free...@com.jkkn.dk wrote: Hi all, I have been encouraged by people on the pf-mailinglist to move this discussion to the current mailinglist since this may be an area in the OS where FreeBSD need to focus on next. First of all I am a happy user of the pf-firewall module and have been for years and think it is really great - the trouble is that lately (since 2008) its getting a bit dusty. The last few years it seem that pf in FreeBSD got a long way away from pf in OpenBSD where it originated - also looking at the ipfilter (ipf) and ipfw - they both to me do not seem to be as complete as pf. So I am curious if any on the mailing could elaborate about what the future of pf in FreeBSD is or should be. a) First of all - are any actively developing pf in FreeBSD? b) We are a major release away from OpenBSD (5.6 coming soon) - is following OpenBSD's pf the past? - should it be? c) We never got the new syntax from OpenBSD 4.7's pf - at the time a long discussion on the pf-mailing list flamed the new syntax saying it would cause FreeBSD administrators too much headache. Today on the list it seems everyone wants it - so would we rather stay on a dead branch than keep up with the main stream? d) Anyone working on bringing FreeBSD up to pf 5.6? - seem dead on the pf-list. e) OpenBSD is retiring ALTQ entirely - any thoughts on that? http://undeadly.org/cgi?action=articlesid=20140419151959 f) IPv6 support?- it seem to be more and more challenged in the current version of pf in FreeBSD and I am (as well as others) introducing more and more IPv6 in networks. E.x. Bugs #179392, #172648, #130381, #127920 and more seriously #124933, which is the bug on not handling IPv6 fragments which have been open since 2008 and where the workaround is necessity to leave an completely open hole in your firewall ruleset to allow all fragments. According to comment in the bug, this have been long gone in OpenBSD. g) Performance, can we live with pf-performance that compared to OpenBSD is slower by a factor of 3 or 4, even after the multi-core support in FreeBSD 10? (Henning Brauer noted that in this talk at http://tech.yandex.ru/events/ yagosti/ruBSD/talks/1488/ (at 33:18 and 36:53)) - credit/Jim Thompson h) Bringing back patches from pfSense? And my most important question: * Should this or could this be a project for the foundation to either do a summer project or funded project to bring this part of the OS up to date? Hope to heard from you all, Best regards, Kristian Kræmmer Nielsen, Odense, Denmark ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions- unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Gleb Smirnoff wrote, On 07/18/2014 13:06: [...] The pf mailing list is about a dozen of active people. Yes, they are vocal on the new syntax. But there also exist a large number of common FreeBSD users who simply use pf w/o caring about syntax and reading pf mailing list. If we destroy the syntax compatibility a very large population of users would be hurt, for the sake of making a dozen happy. I don't agree on this part. Almost every bigger project / application needs to make some uncompatible changes over time. Apache, MySQL, PHP, GNOME, KDE... or FreeBSD itself with recent changes from pkg_* to pkg(ng). Backward compatibility cannot be maintained infinitely if new features should be added. I don't see the reason why PF should be exception. And I am writing this as one who really don't need any new PF features, but I am fine with syntax change in newer FreeBSD major version. There were bigger problem with pf.conf in the past - freebsd-update deleted it and machine was unprotected after reboot. So properly announced syntax change and tutorial to conversions is not problem for me and I hope for some others too. Miroslav Lachman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Fri, 18 Jul 2014 15:06:45 +0400 Gleb Smirnoff gleb...@freebsd.org wrote about Re: Future of pf / firewall in FreeBSD ? - does it have one ?: GS The pf mailing list is about a dozen of active people. Yes, they are GS vocal on the new syntax. But there also exist a large number of common GS FreeBSD users who simply use pf w/o caring about syntax and reading pf GS mailing list. If we destroy the syntax compatibility a very large GS population of users would be hurt, for the sake of making a dozen GS happy. I have thought about this for some time now, and I think I do not agree. I do remember quite well when OpenBSD changed from ipf to pf, and I had to come up with new rules files. Yes, this is a burden for people maintaining these systems, but if the thing is well documented and comes with benefits (like staying in sync with other developers, allowing new features etc.) I doubt that many people will really be minding this. cu Gerrit ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
July 18 2014 6:07 AM, Gleb Smirnoff wrote: Kristian, On Thu, Jul 17, 2014 at 01:12:09AM +0200, Kristian K. Nielsen wrote: K a) First of all - are any actively developing pf in FreeBSD? No one right now. How do we fix this? Can the FreeBSD Foundation step in and provide funding? Our most popular firewall doesn't play well with IPv6 in a time when everyone is pushing IPv6. This is not exactly a good situation to be in. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Mark, On Fri, Jul 18, 2014 at 01:31:04PM +, Mark Felder wrote: M On Thu, Jul 17, 2014 at 01:12:09AM +0200, Kristian K. Nielsen wrote: M K a) First of all - are any actively developing pf in FreeBSD? M M No one right now. M M M How do we fix this? Can the FreeBSD Foundation step in and provide funding? Our most popular firewall doesn't play well with IPv6 in a time when everyone is pushing IPv6. This is not exactly a good situation to be in. I can't speak for FreeBSD Foundation, but I suppose, that they can. However, first you need to find a developer, then fund him. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Gleb Smirnoff gleb...@freebsd.org writes: Hi, Following OpenBSD on features would be cool, but no bulk imports would be made again. Bulk imports produce bad quality of port, and also pf in OpenBSD has no multi thread support. Seems this is the Next Big Thing ™ that will hit OpenBSD/pf according to last conferences slides. Don't know enough about FreeBSD or OpenBSD internals to see if a straight port could be possible. Éric Masson -- AP disait à Grand Neuneu : blagues GNU en signature... Le contraire m'aurait étonné. -+- AP in http://www.le-gnu.net : Le neuneu par l'exemple -+- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Hi Kristian, On 17 Jul 2014, at 01:12, Kristian K. Nielsen free...@com.jkkn.dk wrote: a) First of all - are any actively developing pf in FreeBSD? not directly related to FreeBSD, but I was planning to bring DragonFly's pf to a new feature state. We've had a little bit of discussion over the recent DF SMP fixes on an OpenBSD mailing list, but the outcome was a tad disappointing to say the least. b) We are a major release away from OpenBSD (5.6 coming soon) - is following OpenBSD's pf the past? - should it be? Yes and no. :) I still stand by my claim that SMP is the fork on the road for pf development; having three major BSDs tackling the work in some way or another (NetBSD chose npf, but that's a different story). We should merge newer features for sure, but we have to establish that the forking of pf was an inevitable process and that the custom SMP bits are not going away and need to be maintained separately/individually. c) We never got the new syntax from OpenBSD 4.7's pf - at the time a long discussion on the pf-mailing list flamed the new syntax saying it would cause FreeBSD administrators too much headache. Today on the list it seems everyone wants it - so would we rather stay on a dead branch than keep up with the main stream? I'd say many people are comfortable with an old state of pf (silent majority), but that shouldn't keep us from catching up with newer features (and of course bugfixes). d) Anyone working on bringing FreeBSD up to pf 5.6? - seem dead on the pf-list. Not exactly, but I have a strong interest in this happening and am able to help. :) e) OpenBSD is retiring ALTQ entirely - any thoughts on that? http://undeadly.org/cgi?action=articlesid=20140419151959 The reasoning is sound. I think the direction is good, although one probably can't rip out ALTQ just like that in FreeBSD. f) IPv6 support?- it seem to be more and more challenged in the current version of pf in FreeBSD and I am (as well as others) introducing more and more IPv6 in networks. E.x. Bugs #179392, #172648, #130381, #127920 and more seriously #124933, which is the bug on not handling IPv6 fragments which have been open since 2008 and where the workaround is necessity to leave an completely open hole in your firewall ruleset to allow all fragments. According to comment in the bug, this have been long gone in OpenBSD. Needs to be taken care of. Getting more and more important. ;) g) Performance, can we live with pf-performance that compared to OpenBSD is slower by a factor of 3 or 4, even after the multi-core support in FreeBSD 10? (Henning Brauer noted that in this talk at http://tech.yandex.ru/events/yagosti/ruBSD/talks/1488/ (at 33:18 and 36:53)) - credit/Jim Thompson A factor 3 or 4 times is the proverbial it's one louder. SMP scaling can reach more performance im the long run, and pf can still be tweaked to increase atomic performance, although the physical algorithm limits are a lot more finite than with SMP. h) Bringing back patches from pfSense? Those patches are not available anymore since pfSense changed the visibility of the pfsense-tools.git. I would welcome to see those patches trickle back under a standard BSD license for review and inclusion when viable. But first of all, we need those patches back. Cheers, Franco ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
this is also another important point. If you go onto google and search on how to do this and that under pf, you get a mix of freebsd, and openbsd stuff coming up. I havent analysed it but i think the majority of the stuff is openbsd related. THerefore I find some nice solution to my problem, only to find out a bit later I cant use it because its not supported under freebsd. This is anoying, but more importantly confuses new sysadmins and puts them off adopting pf and possibly a bsd at all. On 18 July 2014 14:12, Gerrit Kühn gerrit.ku...@aei.mpg.de wrote: On Fri, 18 Jul 2014 15:06:45 +0400 Gleb Smirnoff gleb...@freebsd.org wrote about Re: Future of pf / firewall in FreeBSD ? - does it have one ?: GS The pf mailing list is about a dozen of active people. Yes, they are GS vocal on the new syntax. But there also exist a large number of common GS FreeBSD users who simply use pf w/o caring about syntax and reading pf GS mailing list. If we destroy the syntax compatibility a very large GS population of users would be hurt, for the sake of making a dozen GS happy. I have thought about this for some time now, and I think I do not agree. I do remember quite well when OpenBSD changed from ipf to pf, and I had to come up with new rules files. Yes, this is a burden for people maintaining these systems, but if the thing is well documented and comes with benefits (like staying in sync with other developers, allowing new features etc.) I doubt that many people will really be minding this. cu Gerrit ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
that is true and I have not problem using man pages, however thats not the way most of the world work and search engines arent exactly new either. We should be trying to engage more people not less, and part of that is reaching out. On 18 July 2014 15:10, Matt Bettinger iam...@gmail.com wrote: Back in the day we didn't have Google to ask the oracle for cut and paste answers. If the man page is accurate that should be good enough. On Jul 18, 2014 8:26 AM, krad kra...@gmail.com wrote: this is also another important point. If you go onto google and search on how to do this and that under pf, you get a mix of freebsd, and openbsd stuff coming up. I havent analysed it but i think the majority of the stuff is openbsd related. THerefore I find some nice solution to my problem, only to find out a bit later I cant use it because its not supported under freebsd. This is anoying, but more importantly confuses new sysadmins and puts them off adopting pf and possibly a bsd at all. On 18 July 2014 14:12, Gerrit Kühn gerrit.ku...@aei.mpg.de wrote: On Fri, 18 Jul 2014 15:06:45 +0400 Gleb Smirnoff gleb...@freebsd.org wrote about Re: Future of pf / firewall in FreeBSD ? - does it have one ?: GS The pf mailing list is about a dozen of active people. Yes, they are GS vocal on the new syntax. But there also exist a large number of common GS FreeBSD users who simply use pf w/o caring about syntax and reading pf GS mailing list. If we destroy the syntax compatibility a very large GS population of users would be hurt, for the sake of making a dozen GS happy. I have thought about this for some time now, and I think I do not agree. I do remember quite well when OpenBSD changed from ipf to pf, and I had to come up with new rules files. Yes, this is a burden for people maintaining these systems, but if the thing is well documented and comes with benefits (like staying in sync with other developers, allowing new features etc.) I doubt that many people will really be minding this. cu Gerrit ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Back in the day we didn't have Google to ask the oracle for cut and paste answers. If the man page is accurate that should be good enough. On Jul 18, 2014 8:26 AM, krad kra...@gmail.com wrote: this is also another important point. If you go onto google and search on how to do this and that under pf, you get a mix of freebsd, and openbsd stuff coming up. I havent analysed it but i think the majority of the stuff is openbsd related. THerefore I find some nice solution to my problem, only to find out a bit later I cant use it because its not supported under freebsd. This is anoying, but more importantly confuses new sysadmins and puts them off adopting pf and possibly a bsd at all. On 18 July 2014 14:12, Gerrit Kühn gerrit.ku...@aei.mpg.de wrote: On Fri, 18 Jul 2014 15:06:45 +0400 Gleb Smirnoff gleb...@freebsd.org wrote about Re: Future of pf / firewall in FreeBSD ? - does it have one ?: GS The pf mailing list is about a dozen of active people. Yes, they are GS vocal on the new syntax. But there also exist a large number of common GS FreeBSD users who simply use pf w/o caring about syntax and reading pf GS mailing list. If we destroy the syntax compatibility a very large GS population of users would be hurt, for the sake of making a dozen GS happy. I have thought about this for some time now, and I think I do not agree. I do remember quite well when OpenBSD changed from ipf to pf, and I had to come up with new rules files. Yes, this is a burden for people maintaining these systems, but if the thing is well documented and comes with benefits (like staying in sync with other developers, allowing new features etc.) I doubt that many people will really be minding this. cu Gerrit ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 18 July 2014 07:34, krad kra...@gmail.com wrote: that is true and I have not problem using man pages, however thats not the way most of the world work and search engines arent exactly new either. We should be trying to engage more people not less, and part of that is reaching out. Then do the port and maintain it. The problem isn't the desire to keep things up to date, it's a lack of people who want that _and_ are willing/able to do it _and_ are funded somehow. So, please step up! We'll all love you for it. -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 2014-07-18 15:07, Adrian Chadd wrote: On 18 July 2014 07:34, krad kra...@gmail.com wrote: that is true and I have not problem using man pages, however thats not the way most of the world work and search engines arent exactly new either. We should be trying to engage more people not less, and part of that is reaching out. Then do the port and maintain it. The problem isn't the desire to keep things up to date, it's a lack of people who want that _and_ are willing/able to do it _and_ are funded somehow. So, please step up! We'll all love you for it. -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org At vBSDCon Bapt@ volunteered to port the newer pf back to FreeBSD, after spending some hours driving with Henning. I say at EuroBSDCon this year, we get him drunk again, and get him saying he'll do it on video this time, then we'll be all set. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 7/18/2014 4:06 AM, Gleb Smirnoff wrote: K b) We are a major release away from OpenBSD (5.6 coming soon) - is K following OpenBSD's pf the past? - should it be? Following OpenBSD on features would be cool, but no bulk imports would be made again. Bulk imports produce bad quality of port, and also pf in OpenBSD has no multi thread support. I would much rather have a slower pf that actually supports modern networking than a faster one I can't use due to showstopper flaws and missing features. There is currently no viable firewall module for FreeBSD if you want to do things like route IPv6. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Hi! * Should this or could this be a project for the foundation to either do a summer project or funded project to bring this part of the OS up to date? My 2 cents: Yes, this should be tackled by a dedicated project, even better if funded by the foundation. -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
