Re: [pfSense-discussion] Unfork m0n0wall
Bennett wrote: This answers one of my biggest questions about the fork. I've been fixated on the package system (though my previous mention of it was brief), thinking it was a solution for both projects. I had envisioned moving everything that isn't a core feature into an optional module. Instead of m0n0wall is too resource-intensive to run on microsystem X, you get m0n0wall will run on microsystem X with features A, B, and C, but not D. I wasn't aware that m0n0wall's file system makes this whole idea infeasible. Perhaps I should troll the m0n0wall list... :) go for it. You'd still get me replying to your messages, with the same stuff mostly. :) But it'll never change to be a full blown hard drive install, and that's precisely where the split between the two is justified. I personally think the embedded pfsense image should be dropped when/if m0n0wall gets on FreeBSD 6. At that point, depending on where m0n0wall 1.3 ends up, it may very well be a wasted effort to put out an embedded image where that's m0n0wall's territory and where it excels. Still, I think moving EVERY non-core feature (e.g., captive portal, load balancing, CARP, even VPN) into an optional module is the way to go for pfSense. Then, only the features a user needs are installed. Umm, no. Virtually all of that is in-kernel stuff, so the only thing (most of it at least) you could add on would be the GUI pages. No sense in separating that. I also got the impression from the pfSense FAQs (yes, I did do some research before posting) that there was a bit more code sharing than there actually is, so I thought the projects were not quite as separate as they are. I understand now that that is not the case, and hence my concerns about patchy code were unjustified. Furthermore, Colin said it's a one-way street (which I assume goes from pfSense to m0n0?), No, the other way around actually. I don't think a single line of pfsense code has made it into m0n0wall at this point. That'll likely happen more once work on 1.3 gets going. so there's no duplicated work since m0n0wall can incorporate, say, the certificate manager that pfSense has already developed. well, not really for many of the things at this point. the back end of the certificate manager is, iirc, almost as big as the entire m0n0wall image. At any rate, it's far too large for the way the file system currently works. that's true of many other things as well that I'm not recalling ATM..
Re: [pfSense-discussion] Unfork m0n0wall
Chris Buechler wrote: Bennett wrote: Perhaps I should troll the m0n0wall list... :) go for it. You'd still get me replying to your messages, with the same stuff mostly. :) Chris won't be the only one, either. :-) But it'll never change to be a full blown hard drive install, and that's precisely where the split between the two is justified. I personally think the embedded pfsense image should be dropped when/if m0n0wall gets on FreeBSD 6. At that point, depending on where m0n0wall 1.3 ends up, it may very well be a wasted effort to put out an embedded image where that's m0n0wall's territory and where it excels. depends on how much of the various packages (802.1x/WPA, plethora of wireless drivers, carp, altq, serial console, ...) are picked up in m0n0. Each of these will serve to make m0n0 a larger, more complicated system, and Manuel will have to cut the baby somewhere. So, I'd rather the embedded image (or at least the option to cut an embedded image) be kept. Keeping it means testing it, too, so its likely that the image itself should be kept. jim
[pfSense-discussion] Unfork m0n0wall
I've been looking for an open source firewall. I found m0n0wall, IPCop, and few others. I thought m0n0wall was great, but then I came across pfSense, and it was even better, picking up where m0n0wall left off. However, this fork of m0n0wall is a bit unnerving. Yes, I know you have radically different goals, but you also have similar goals and will face similar issues. This fork detracts from BOTH projects because you've effectively cut the manpower for each project roughly in half (since everyone could be working on one project instead of two) while doubling the work (since each project will be duplicating work). And let's not forget the user base is split, too, so each project has half the support and testers. Even if you're sharing some code so you're not both reinventing the wheel, you still have to merge disjoint code as m0n0wall tries to add pfSense enhancements into their code and vice versa. As a programmer, I know what all this patching is going to do to the code. As you exchange code back and forth, m0n0wall is going to have some pfSense-specific code that they'll patch to retrofit into m0n0wall and then give it back to pfSense who will add some patches to the m0n0wall patches...Eventually, this bloated mess of patches is so convoluted that no one knows how it works and you're on your way to security holes and compromised networks. Thus, either you've doubled the work with half the developers/testers or you've doomed the code to buggy patches on top of patches. This makes me question the founders of pfSense...Did they not foresee this when they decided to fork? And these short-sighted individuals are who I am counting on to protect my valuable network? Or is this some sort of ego thing? Did the other m0n0wall programmers hurt their feelings so they ran off and made their own little project? Or maybe the m0n0wall developers are unreasonable jerks and so pfSense politely forked rather than bash heads. But those unreasonable developers are the ones who wrote the original m0n0wall code that you're using... It seems a wiser course of action would be to NOT FORK and instead focus on incorporating an enhanced packaging system within m0n0wall that would allow users to install/uninstall features on-demand. Thus, m0n0wall/pfSense could still be installed on embedded systems with a streamlined core, and then expanded with additional functionality as needed. (You could have your cake and eat it, too, but without the fork). ;) In addition, removing unused features will help minimize exposure to security holes. So, having said all that, why should I consider pfSense for my firewall when it's written by a bunch of unreasonable jerks and short-sighted egoists who are churning out a insecure, bloated spaghetti? (Please don't get me wrong--I plan on using pfSense to secure my network and most likely at least two of my clients' networks, too. I'm just looking for answers to quell my concerns.) --Bennett
Re: [pfSense-discussion] Unfork m0n0wall
Bennett wrote: I've been looking for an open source firewall. I found m0n0wall, IPCop, and few others. I thought m0n0wall was great, but then I came across pfSense, and it was even better, picking up where m0n0wall left off. However, this fork of m0n0wall is a bit unnerving. Yes, I know you have radically different goals, but you also have similar goals and will face similar issues. This fork detracts from BOTH projects because you've effectively cut the manpower for each project roughly in half (since everyone could be working on one project instead of two) while doubling the work (since each project will be duplicating work). And let's not forget the user base is split, too, so each project has half the support and testers. You're assuming that pfSense has half the users and testers, an assumption that I find unlikely in view of pfSense's current status (it has yet to be released as a production version, though that day is coming.) Even if you're sharing some code so you're not both reinventing the wheel, you still have to merge disjoint code as m0n0wall tries to add pfSense enhancements into their code and vice versa. Where the goals of pfSense and m0n0(wall) are similar, this could be true, but the goals are more different than similar. Manuel (whom I don't profess to speak for, so I'm willing to be corrected) wants m0n0wall to continue to focus on small(er) embedded systems (such as the Soekris and PC Engines boards, along with old(er) PCs), with limited CPU (486 equivalents clocked at 100MHz), memory (sometimes as little as 64MB) and storage (there is great reluctance to increase the CF image beyond current the 8MB 'cap'), while making no sacrifices to performance (normally expressed in terms of throughput) on these platforms. Thus, the fallback to 4.11 for the 1.2 series release after FreeBSD 5.3 failed to live up to the performance metrics of the 4.11-based releases. Manuel describes it quite well here: http://doc.m0n0.ch/handbook/faq-goals.html pfSense shares none of these constraints. Indeed, in direct opposition to m0n0wall, pfSense *is* intended to be an enterprise-ready firewall, and *is* targeted at a class of machines with more capacity that the constraint envelope chosen for m0n0wall. Quoting the pfSense FAQ: pfSense requires a machine with at least a 133 MHz processor but we suggest using a 400+ MHz machine. 128+ MB of RAM and a 1 GB minimum hard drive space is recommended. (pfSense can be run with less than this, of course). As a programmer, I know what all this patching is going to do to the code. As you exchange code back and forth, m0n0wall is going to have some pfSense-specific code that they'll patch to retrofit into m0n0wall and then give it back to pfSense who will add some patches to the m0n0wall patches...Eventually, this bloated mess of patches is so convoluted that no one knows how it works and you're on your way to security holes and compromised networks. You haven't proved your assumption here. (I haven't disproved it either.) Thus, either you've doubled the work with half the developers/testers or you've doomed the code to buggy patches on top of patches. This makes me question the founders of pfSense...Did they not foresee this when they decided to fork? And these short-sighted individuals are who I am counting on to protect my valuable network? Or is this some sort of ego thing? Did the other m0n0wall programmers hurt their feelings so they ran off and made their own little project? Or maybe the m0n0wall developers are unreasonable jerks and so pfSense politely forked rather than bash heads. But those unreasonable developers are the ones who wrote the original m0n0wall code that you're using... It seems a wiser course of action would be to NOT FORK and instead focus on incorporating an enhanced packaging system within m0n0wall that would allow users to install/uninstall features on-demand. Thus, m0n0wall/pfSense could still be installed on embedded systems with a streamlined core, and then expanded with additional functionality as needed. (You could have your cake and eat it, too, but without the fork). ;) In addition, removing unused features will help minimize exposure to security holes. So, having said all that, why should I consider pfSense for my firewall when it's written by a bunch of unreasonable jerks and short-sighted egoists who are churning out a insecure, bloated spaghetti? this is a troll. I won't feed the troll. (Please don't get me wrong--I plan on using pfSense to secure my network and most likely at least two of my clients' networks, too. I'm just looking for answers to quell my concerns.) My suggestion is that you try to be more polite. Jim
Re: [pfSense-discussion] Unfork m0n0wall
* Bennett [EMAIL PROTECTED] [2005-11-27 01:58:17 -0600]: However, this fork of m0n0wall is a bit unnerving. Yes, I know you have radically different goals, but you also have similar goals and will face similar issues. This fork detracts from BOTH projects because you've effectively cut the manpower for each project roughly in half (since everyone could be working on one project instead of two) while doubling the work (since each project will be duplicating work). And let's not forget the user base is split, too, so each project has half the support and testers. pfSense and m0n0wall are in a few respects very similar projects, but there are also several important differences that would make merging back into m0n0wall's codebase very difficult and quite probably harmful. m0n0wall has always targeted embedded systems where resources are at a premium, which is why Manuel is generally more conservative when it comes to adding or changing major pieces of code. In contrast, pfSense targets machines that are not quite as minimal. Making this assumption about the machines that pfSense will be installed on allows us to implement amenities such as the package system, wizards, SSH, and so on. These are all things that would be very difficult to squeeze into m0n0wall's base without compromising one of that project's main goals. Even if you're sharing some code so you're not both reinventing the wheel, you still have to merge disjoint code as m0n0wall tries to add pfSense enhancements into their code and vice versa. As a programmer, I know what all this patching is going to do to the code. As you exchange code back and forth, m0n0wall is going to have some pfSense-specific code that they'll patch to retrofit into m0n0wall and then give it back to pfSense who will add some patches to the m0n0wall patches...Eventually, this bloated mess of patches is so convoluted that no one knows how it works and you're on your way to security holes and compromised networks. Though we occasionally merge bugfixes and features from m0n0wall, to the best of my knowledge this has mostly been a 'one-way street'. At this point much of our base code has diverged significantly from the original m0n0wall codebase, and many of the features we have worked on since the fork will likely not make it back into m0n0 for the reasons described above. Thus, either you've doubled the work with half the developers/testers or you've doomed the code to buggy patches on top of patches. This makes me question the founders of pfSense...Did they not foresee this when they decided to fork? And these short-sighted individuals are who I am counting on to protect my valuable network? Or is this some sort of ego thing? Did the other m0n0wall programmers hurt their feelings so they ran off and made their own little project? Or maybe the m0n0wall developers are unreasonable jerks and so pfSense politely forked rather than bash heads. But those unreasonable developers are the ones who wrote the original m0n0wall code that you're using... As I've already stated, there's really no reason to fear that pfSense is going to collapse under the weight of the patches we're forced to juggle, because there aren't many to begin with. Also, it is my understanding that Scott and Chris originally forked because of Manuel's (obvious) resistance to taking his project in an entirely new direction. Few if any bridges were burned. It most certainly was not an 'ego thing'. Skipping past the troll at the end, Colin pgp3MFmHTBd4f.pgp Description: PGP signature
RE: [pfSense-discussion] Unfork m0n0wall
I agree completely with cloin we use both monowall and pfsense. Pfsense is great if you have some good hardware but monowall is great on embedded platforms lightweight reliable and not to feature loaded. Great for transpernet bridging 801.b aps and clients. Super for replacing that home firewall with something robust. Pfsense is feature packed and takes a lot longer to get a good working configuration, lots of extra packages and tweaks for those enterprise firewall solutions. Great for datacenter work or large lans. Also I am subscribed to both lists and find the problems on each list and the utilizations are very different. Just my two cents worth. -Original Message- From: Colin Smith [mailto:[EMAIL PROTECTED] Sent: Sunday, November 27, 2005 4:32 PM To: discussion@pfsense.com Subject: Re: [pfSense-discussion] Unfork m0n0wall * Bennett [EMAIL PROTECTED] [2005-11-27 01:58:17 -0600]: However, this fork of m0n0wall is a bit unnerving. Yes, I know you have radically different goals, but you also have similar goals and will face similar issues. This fork detracts from BOTH projects because you've effectively cut the manpower for each project roughly in half (since everyone could be working on one project instead of two) while doubling the work (since each project will be duplicating work). And let's not forget the user base is split, too, so each project has half the support and testers. pfSense and m0n0wall are in a few respects very similar projects, but there are also several important differences that would make merging back into m0n0wall's codebase very difficult and quite probably harmful. m0n0wall has always targeted embedded systems where resources are at a premium, which is why Manuel is generally more conservative when it comes to adding or changing major pieces of code. In contrast, pfSense targets machines that are not quite as minimal. Making this assumption about the machines that pfSense will be installed on allows us to implement amenities such as the package system, wizards, SSH, and so on. These are all things that would be very difficult to squeeze into m0n0wall's base without compromising one of that project's main goals. Even if you're sharing some code so you're not both reinventing the wheel, you still have to merge disjoint code as m0n0wall tries to add pfSense enhancements into their code and vice versa. As a programmer, I know what all this patching is going to do to the code. As you exchange code back and forth, m0n0wall is going to have some pfSense-specific code that they'll patch to retrofit into m0n0wall and then give it back to pfSense who will add some patches to the m0n0wall patches...Eventually, this bloated mess of patches is so convoluted that no one knows how it works and you're on your way to security holes and compromised networks. Though we occasionally merge bugfixes and features from m0n0wall, to the best of my knowledge this has mostly been a 'one-way street'. At this point much of our base code has diverged significantly from the original m0n0wall codebase, and many of the features we have worked on since the fork will likely not make it back into m0n0 for the reasons described above. Thus, either you've doubled the work with half the developers/testers or you've doomed the code to buggy patches on top of patches. This makes me question the founders of pfSense...Did they not foresee this when they decided to fork? And these short-sighted individuals are who I am counting on to protect my valuable network? Or is this some sort of ego thing? Did the other m0n0wall programmers hurt their feelings so they ran off and made their own little project? Or maybe the m0n0wall developers are unreasonable jerks and so pfSense politely forked rather than bash heads. But those unreasonable developers are the ones who wrote the original m0n0wall code that you're using... As I've already stated, there's really no reason to fear that pfSense is going to collapse under the weight of the patches we're forced to juggle, because there aren't many to begin with. Also, it is my understanding that Scott and Chris originally forked because of Manuel's (obvious) resistance to taking his project in an entirely new direction. Few if any bridges were burned. It most certainly was not an 'ego thing'. Skipping past the troll at the end, Colin
Re: [pfSense-discussion] Unfork m0n0wall
On 11/27/05, Bennett [EMAIL PROTECTED] wrote: I've been looking for an open source firewall. I found m0n0wall, IPCop, and few others. I thought m0n0wall was great, but then I came across pfSense, and it was even better, picking up where m0n0wall left off. I think you just summarized the fork right here. Picking up where m0n0wall left off - if this was m0n0 with a few patches here and there, it wouldn't pick up where m0n0 left off, it'd be m0n0+patches. patches...Eventually, this bloated mess of patches is so convoluted that no one knows how it works and you're on your way to security holes and compromised networks. m0n0 has a concept of a single administrator (as currently does pfSense). Unless the OS or web server has a remote vulnerability I don't see any merit to your claim. We are adding xmlrpc functionality which will over time increase the security risk of an exposed GUI, but until multiple administrators are added, that's not much of a risk increase (same auth code). Thus, either you've doubled the work with half the developers/testers or you've doomed the code to buggy patches on top of patches. This makes me question the founders of pfSense...Did they not foresee this when they decided to fork? And these short-sighted individuals are who I am counting on to protect my valuable network? Or is this some sort of ego thing? Did the other m0n0wall programmers hurt their feelings so they ran off and made their own little project? Or maybe the m0n0wall developers are unreasonable jerks and so pfSense politely forked rather than bash heads. But those unreasonable developers are the ones who wrote the original m0n0wall code that you're using... Never used m0n0, so I can't really speak about the original fork. I can however say why I started submitting patches to pfSense and not m0n0. pfSense uses pf, a filter software that I am comfortable with, like, and has features far greater than ipfilter has. I stumbled onto pfSense after purchasing a 4801 and finding that the only embedded firewall project ran ipfilter, which I didn't want to run, and had started to write my own (for myself, it would have NEVER been released). To be frank, I work on pfSense BECAUSE it uses pf. If m0n0 switched today, I'd probably still stick with pfSense development, I know the codebase pretty well, I like it's openness. I also see a lot of issues in the codebase, stuff that I'd like to rewrite, stuff that once rewritten will have zero chance in hell of being backported to m0n0 or receiving further updates from m0n0. Again, an example of how the fork is going it's own way and developing it's own code, not just patches. So, having said all that, why should I consider pfSense for my firewall when it's written by a bunch of unreasonable jerks and short-sighted egoists who are churning out a insecure, bloated spaghetti? (Please don't get me wrong--I plan on using pfSense to secure my network and most likely at least two of my clients' networks, too. I'm just looking for answers to quell my concerns.) I've got a better idea. After all you've said, why are you choosing pfSense over m0n0? What have we done right that's made you want to choose pfSense over m0n0? I assume we've done _something_ right for you to choose an alpha project over a released product. --Bill
Re: [pfSense-discussion] Unfork m0n0wall
On 11/27/05, Bennett [EMAIL PROTECTED] wrote: Email address created just to troll us. I already see issues. I've been looking for an open source firewall. I found m0n0wall, IPCop, and few others. I thought m0n0wall was great, but then I came across pfSense, and it was even better, picking up where m0n0wall left off. However, this fork of m0n0wall is a bit unnerving. Yes, I know you have radically different goals, but you also have similar goals and will face similar issues. This fork detracts from BOTH projects because you've effectively cut the manpower for each project roughly in half (since everyone could be working on one project instead of two) while doubling the work (since each project will be duplicating work). And let's not forget the user base is split, too, so each project has half the support and testers. I suggest reading through the m0n0wall archives. A lot of ideas that are in pfSense have been shot down. You haven't done you're homework. Even if you're sharing some code so you're not both reinventing the wheel, you still have to merge disjoint code as m0n0wall tries to add pfSense enhancements into their code and vice versa. As a programmer, I know what all this patching is going to do to the code. As you exchange code back and forth, m0n0wall is going to have some pfSense-specific code that they'll patch to retrofit into m0n0wall and then give it back to pfSense who will add some patches to the m0n0wall patches...Eventually, this bloated mess of patches is so convoluted that no one knows how it works and you're on your way to security holes and compromised networks. See above. Manuel is very conservative of what he adds (which is good, because his goals are different). Either way, our codebase in a lot of areas are quite different now. Thus, either you've doubled the work with half the developers/testers or you've doomed the code to buggy patches on top of patches. This makes me question the founders of pfSense...Did they not foresee this when they decided to fork? And these short-sighted individuals are who I am counting on to protect my valuable network? Or is this some sort of ego thing? Did the other m0n0wall programmers hurt their feelings so they ran off and made their own little project? Or maybe the m0n0wall developers are unreasonable jerks and so pfSense politely forked rather than bash heads. But those unreasonable developers are the ones who wrote the original m0n0wall code that you're using... That is not true, a lot of our developers have never even used m0n0wall. Of course Chris and I thought a lot of these items through when we decided to do this. Chris did write 90% of the manual. Question: Why do you keep using words like unreasonable and jerks? Please show me some material that hvae gotten your panties in an uproar. At this point you are now our king troll. We should find a name for you. It seems a wiser course of action would be to NOT FORK and instead focus on incorporating an enhanced packaging system within m0n0wall that would allow users to install/uninstall features on-demand. Thus, m0n0wall/pfSense could still be installed on embedded systems with a streamlined core, and then expanded with additional functionality as needed. (You could have your cake and eat it, too, but without the fork). ;) In addition, removing unused features will help minimize exposure to security holes. Reread my first response. Packaging had been discussed MANY times on the m0n0wall list. Nobody seemed to keen about it. So, having said all that, why should I consider pfSense for my firewall when it's written by a bunch of unreasonable jerks and short-sighted egoists who are churning out a insecure, bloated spaghetti? (Please don't get me wrong--I plan on using pfSense to secure my network and most likely at least two of my clients' networks, too. I'm just looking for answers to quell my concerns.) Here we go again. Unreasonable jerks. So I guess you're referring to me.Again, what has got your panties in an uproar? At this point I would rather you go use IPCOP. Throw on the Sesame Street theme on your favorite 45 player and don't look back. Good day.
Re: [pfSense-discussion] Unfork m0n0wall
Colin Smith wrote: Also, it is my understanding that Scott and Chris originally forked because of Manuel's (obvious) resistance to taking his project in an entirely new direction. Few if any bridges were burned. It most certainly was not an 'ego thing'. I won't bother responding to most of this, but I will say this much. Someone emailed Manuel (m0n0wall founder and primary developer) and me (primary m0n0wall list poster and doc writer, as well as co-founder of this project) suggesting we merge the projects and not split efforts. Manuel replied before I got a chance to, and he's on the same page as us. Paraphrasing what Manuel said, the goals of the project are significantly different enough that it makes sense to keep them separate. m0n0wall's focus on embedded platforms leaves it with a file system that isn't suitable for a packaging system, and while it might change slightly for version 1.3, it will still not be suitable for most packages because it will never be a normal file system. Manuel is a stickler for doing things the *right* way, which is what has made m0n0wall a killer project. But that's also left a lot of users out in the cold, without the ability to do things they want or need to do. Manuel's stance is these things don't belong on a firewall (whatever they might be). And I agree. Things like ntop, various network management tools, and all kinds of similar things, don't belong on a firewall in an ideal network environment. But, when you look at a network that only has maybe 3-5 machines, or maybe even up to 10-20, segregating these services leaves you in a situation where you have more servers and administrative machines than end user machines (or at least an unacceptably expensive ratio). It's better to have these things on the firewall than to not have them at all, when you have no other feasible options (for non-technical reasons, usually cost). In short, Manuel agrees with what we're doing, we obviously agree with what we're doing, and there's absolutely no animosity between the projects, so there really isn't any room for argument.
Re: [pfSense-discussion] Unfork m0n0wall
plainly said if you unforked pfSense and M0n0wall you would essentially not have alot of what both offer because then they would not be reaching such diverse goals, both projects are good, and have solidbasis to exists, its like saying unfork BSD... theres a purpose for them to exists, and other ides will grow from these projects im sure, even a NAS system has grown from m0n0wall. If you dont like what they are doing create your own, or add to whats missing for what you need, hence the reason i track both projects and have a customized build. On Sun, 2005-11-27 at 16:42 -0500, Chris Buechler wrote: Colin Smith wrote: Also, it is my understanding that Scott and Chris originally forked because of Manuel's (obvious) resistance to taking his project in an entirely new direction. Few if any bridges were burned. It most certainly was not an 'ego thing'. I won't bother responding to most of this, but I will say this much. Someone emailed Manuel (m0n0wall founder and primary developer) and me (primary m0n0wall list poster and doc writer, as well as co-founder of this project) suggesting we merge the projects and not split efforts. Manuel replied before I got a chance to, and he's on the same page as us. Paraphrasing what Manuel said, the goals of the project are significantly different enough that it makes sense to keep them separate. m0n0wall's focus on embedded platforms leaves it with a file system that isn't suitable for a packaging system, and while it might change slightly for version 1.3, it will still not be suitable for most packages because it will never be a normal file system. Manuel is a stickler for doing things the *right* way, which is what has made m0n0wall a killer project. But that's also left a lot of users out in the cold, without the ability to do things they want or need to do. Manuel's stance is these things don't belong on a firewall (whatever they might be). And I agree. Things like ntop, various network management tools, and all kinds of similar things, don't belong on a firewall in an ideal network environment. But, when you look at a network that only has maybe 3-5 machines, or maybe even up to 10-20, segregating these services leaves you in a situation where you have more servers and administrative machines than end user machines (or at least an unacceptably expensive ratio). It's better to have these things on the firewall than to not have them at all, when you have no other feasible options (for non-technical reasons, usually cost). In short, Manuel agrees with what we're doing, we obviously agree with what we're doing, and there's absolutely no animosity between the projects, so there really isn't any room for argument.
RE: [pfSense-discussion] Unfork m0n0wall
First off, let me apologize if I was too offensive. I wasn't trolling--that was my imagination playing devil's advocate, and meant to be rhetorical. As I am beginning to understand the fork, these wild ideas have no justification (well, maybe one or two still do...). :) Chris Buechler wrote: m0n0wall's focus on embedded platforms leaves it with a file system that isn't suitable for a packaging system, and while it might change slightly for version 1.3, it will still not be suitable for most packages because it will never be a normal file system. This answers one of my biggest questions about the fork. I've been fixated on the package system (though my previous mention of it was brief), thinking it was a solution for both projects. I had envisioned moving everything that isn't a core feature into an optional module. Instead of m0n0wall is too resource-intensive to run on microsystem X, you get m0n0wall will run on microsystem X with features A, B, and C, but not D. I wasn't aware that m0n0wall's file system makes this whole idea infeasible. Perhaps I should troll the m0n0wall list... :) Still, I think moving EVERY non-core feature (e.g., captive portal, load balancing, CARP, even VPN) into an optional module is the way to go for pfSense. Then, only the features a user needs are installed. The other features aren't there, and so they can't be used to comprise the system. In addition, a robust package system would open the door for third-party development of items beyond the scope of a firewall, like antispam and antivirus filters, or even just simple packages end-users could write to customize their system, like automatically dialing a pager number if the WAN goes down. As the community grows, there could even be some sort of certification for modules that pass security tests so users know which modules are deemed safe. But I digress. Let me get back to the original thread. I also got the impression from the pfSense FAQs (yes, I did do some research before posting) that there was a bit more code sharing than there actually is, so I thought the projects were not quite as separate as they are. I understand now that that is not the case, and hence my concerns about patchy code were unjustified. Furthermore, Colin said it's a one-way street (which I assume goes from pfSense to m0n0?), so there's no duplicated work since m0n0wall can incorporate, say, the certificate manager that pfSense has already developed. (But the workforce/testers are still divided into whatever their respective ratios are.) You have all done a good job in answering my concerns. Very enlightening. And thanks for your speedy replies. It shows the pfSense community is alive and active, which further sets my mind at ease. I'll hold off on responding to everyone's comments individually, except please let me do one intentional troll: TROLL Scott, you've got it all wrong. In my overactive imagination, unreasonable jerks would refer to Manuel while you would be one of the short-sighted egoists. :) /TROLL --Bennett
RE: [pfSense-discussion] Unfork m0n0wall
I think you need to read thru the code. What is pfsense/monowall ? In simple terms it's freebsd 6.x and freebsd 4.x with a web gui and some minor patches. Each creates a bunch of firewall rules for either ipfilter (m0n0) or pf (pfsense). The OS is more or less a stock freebsd with a bunch of stuff removed, pluss a different installer and some minor patches. So the only security flaws you will find will in most cases be rules that are created wrong and thus exposes the firewall in some unfortunate way (I would say that this will be very rare). Or it will be exposed services like ssh or the minihttpd or whatever package(s) you install. There is a reason a lot of addons are packages and not in the base. So basically you have a OS and some addons, and on top you have a GUI so that the end user will not have to play with a bunch of config files. Everything PFsense does can be done with freebsd6 and programs available for it. If you read thru the code you would know this by now. And merging m0n0 that creates a ipfilter config with pfsense that creates a pf config would not be smart at all. -lsf -Original Message- From: Bennett [mailto:[EMAIL PROTECTED] Sent: 27. november 2005 08:58 To: discussion@pfsense.com Subject: [pfSense-discussion] Unfork m0n0wall I've been looking for an open source firewall. I found m0n0wall, IPCop, and few others. I thought m0n0wall was great, but then I came across pfSense, and it was even better, picking up where m0n0wall left off. However, this fork of m0n0wall is a bit unnerving. Yes, I know you have radically different goals, but you also have similar goals and will face similar issues. This fork detracts from BOTH projects because you've effectively cut the manpower for each project roughly in half (since everyone could be working on one project instead of two) while doubling the work (since each project will be duplicating work). And let's not forget the user base is split, too, so each project has half the support and testers. Even if you're sharing some code so you're not both reinventing the wheel, you still have to merge disjoint code as m0n0wall tries to add pfSense enhancements into their code and vice versa. As a programmer, I know what all this patching is going to do to the code. As you exchange code back and forth, m0n0wall is going to have some pfSense-specific code that they'll patch to retrofit into m0n0wall and then give it back to pfSense who will add some patches to the m0n0wall patches...Eventually, this bloated mess of patches is so convoluted that no one knows how it works and you're on your way to security holes and compromised networks. Thus, either you've doubled the work with half the developers/testers or you've doomed the code to buggy patches on top of patches. This makes me question the founders of pfSense...Did they not foresee this when they decided to fork? And these short-sighted individuals are who I am counting on to protect my valuable network? Or is this some sort of ego thing? Did the other m0n0wall programmers hurt their feelings so they ran off and made their own little project? Or maybe the m0n0wall developers are unreasonable jerks and so pfSense politely forked rather than bash heads. But those unreasonable developers are the ones who wrote the original m0n0wall code that you're using... It seems a wiser course of action would be to NOT FORK and instead focus on incorporating an enhanced packaging system within m0n0wall that would allow users to install/uninstall features on-demand. Thus, m0n0wall/pfSense could still be installed on embedded systems with a streamlined core, and then expanded with additional functionality as needed. (You could have your cake and eat it, too, but without the fork). ;) In addition, removing unused features will help minimize exposure to security holes. So, having said all that, why should I consider pfSense for my firewall when it's written by a bunch of unreasonable jerks and short-sighted egoists who are churning out a insecure, bloated spaghetti? (Please don't get me wrong--I plan on using pfSense to secure my network and most likely at least two of my clients' networks, too. I'm just looking for answers to quell my concerns.) --Bennett
RE: [pfSense-discussion] Unfork m0n0wall
Bill Marquette wrote: I've got a better idea. After all you've said, why are you choosing pfSense over m0n0? What have we done right that's made you want to choose pfSense over m0n0? I assume we've done _something_ right for you to choose an alpha project over a released product. Actually, I AM going with m0n0wall at one of my clients, because: (1) they're running a Pentium with 32MB (which I suppose only serves to justify the fork), and (2) because pfSense is still alpha. Once pfSense is stable, I'll probably switch them to pfSense because pfSense has a certificate manager for their VPN and CARP for failover that they requested. As for me at home, I'm currently choosing pfSense over m0n0wall for largely superficial reasons, like the certificate manager and better aliases. However, I'm also thinking long-term here. I recognize that m0n0wall will always be more limited than pfSense because of its more restrictive requirements. Hence, I expect pfSense will ultimately have more features that I anticipate my clients will need. I run it at home so I can muck up my own network before screwing up my clients'. I'd like to know that the product I plan on convincing my clients to use is going to be around in few years. That's why I posted initially. I wanted to know more about the fork. I wanted to know that it wasn't some half-baked spin-off that will never come to fruition, and possibly even killing off m0n0wall by splitting the community so thin that neither project has the support it needs to continue. In a nutshell, THAT was my concern, and, thanks to your responses, I know this is NOT the case. Again, thank you all for your replies. --Bennett
RE: [pfSense-discussion] Unfork m0n0wall
Espen Johansen wrote: I think you need to read thru the code. ... If you read thru the code you would know this by now. Surely you're joking. Are you saying anyone who has questions about m0n0wall or pfSense should just read the code instead asking questions to the people who actually wrote the code? Who exactly do you think is using pfSense? Yes, I am a programmer, but my Unix experience is limited to 1 semester in college many moons ago where I wrote a simplistic client/server daemon, and my network programming experience is limited to sockets. I could probably figure everything out eventually, but you're also suggesting that I read the source to m0n0wall, which I don't plan on using, and compare it to pfSense. So now I'm supposed to read the source to every system I plan to use, plus ones I'm not planning to use before I ask questions about any of them? If I did all that, I would wouldn't have time to troll discussion groups, would I? (Or am I obtuse and that's the whole point?) --Bennett
