Another PFSense+FreeNAS argument
-
Yes I've read the Sticky, and heard a number of objections.
http://forum.pfsense.org/index.php/topic,10201.0.htmlI'd like to request the full integration of pfsense and freenas into a single unified project. I believe this would provide the following benefits:
- Improved security all around
With more eyes and less code running there would be less chance of security holes seeping into core code and fewer bits of redundant code that have to be developed and maintained separately
By allowing the two teams to merge and double the number of people paying attention to common elements like the freebsd kernel, web interface, installer, configuration, and modules system, security can only be improved.
- Improved efficiency for edge cases and low security points
It's not uncommon for a file server or other application server to be present on multiple subnets. It's not uncommon for routers to be ideally located to provide some degree of services. Not every network junction is a high security fortress.
in similar fashion to point 1, double the developer force can optimize the efficiency of the implementation and interface for the simple tasks, such as the web interface, installer, configuration, and modules system.
- Common use cases, Common feature set
There are many common usecases for pfsense. For example, some pfsensei are used for providing network services other than routing. Some freenas are used for similar purposes. Neither is solely an edge router or a NAS box.
For example, many NAS boxen need firewalls, and many routers are used to provide services such as http, dns, and dhcp
- zfs
You might argue that ZFS has no business on the Router. You're WRONG. ZFS provides redundancy, failover, integrity, seamless backups, point-in-time restores and rollbacks, and a few other features all of which are useful. Furthermore, under a light load, such as that pfsense provides, ZFS can do all this while fitting comfortably within 512MiB of RAM. Currently running a pfsense on a moderate home network and fitting comfortably within 512MiB without tweaking for memory usage, I can say with a modicum of certainty that pfsense could run ZFS on a 1GiB system without issue and without significant performance tuning.
FreeNAS already has working ZFS fully implemented with most of these features.
- There's no reason the full featureset of both systems need to be installed at each install.
I think all the main functionality except for some core features should be migrated out to packages
I actually propose 4 new packages be released. a pfnas edge, pfnas home server, pfnas core, and pfnas all-in-one(Name to be adjusted). The pfnas edge would serve the purpose of pfsense now. the pfnas home server would provide basically the functionality of freenas now. Either would be able to install the modules or features of the other as plugins. The pfnas core would include basically the installer and the command line interface as well as the ability to to install ANY feature as a module. Basically a stripped down, add-only-what-you-need base. I believe the last package is optional. pfnas all-in-one is basically that. The core configuration, plus all of edge and all of home server. It would be for people who just want to throw it up and experiment, or who need something like a low security router+file server between two LANs or similar. It should be behind a disclaimer, and possibly not even on the main download page, but only accessible by accessing the mirrors directly.I'm envisioning something similar to how eclipse functions now, where any feature can be added or removed from any install of eclipse With the way pfsense works now with packages and freenas developing that feature, it's a perfectly logical next step for both.
For all the reasons above, and the fact that those reasons address most of the common concerns and hilight how they're actually cause for celebration rather than alarm, I'd like to request that the issue be reconsidered thoroughly and properly, and without the derisive "That's a bad idea because ____." with no followup or explanation comments.
-
I'd like to request the full integration of pfsense and freenas into a single unified project. I believe this would provide the following benefits:
Fork them both, merge them, and start a new FOSS project? Might I suggest pfNAS as a name?
-
I'd like to request the full integration of pfsense and freenas into a single unified project. I believe this would provide the following benefits:
Fork them both, merge them, and start a new FOSS project? Might I suggest pfNAS as a name?
I thought that this issue was fairly well addressed by the majority of the following text. Any single user or group of users forking either project to these ends would NOT result in the majority of the most important benefits, which stem from the joining of the developer base and the doubling of eyes on the various critical sections.
As much as I appreciate that anybody can fork an existing FOSS project, I believe that using that ability over-generously, as has been done in the past results in a thinning of the various communities developer bases, and increased repetition of code. A problem that currently plagues both pfSense and FreeNAS.
As an example, I cite two features that are currently under development: zfs root support on pfSense and Packages on FreeNAS. Each of these features has been fully developed and flushed out by one platform and is now under development by it's counterpoint. zfs root support has been working perfectly in FreeNAS for several versions now, whereas pfSense is just developing it, reproducing the code and effort performed by the FreeNAS people. Similarly, FreeNAS just started working on packages support a few revisions ago, yet packages have been a working feature of pfsense since before the 2.0RC branches at least (I remember packages back in the 1x days).
-
While I can understand the ease of use this would provide. A security device (firewall/router) should not also be a file storage/server device.
I would stop using pfsense if this was built in, talk about a security nightmare.
-
While I can understand the ease of use this would provide. A security device (firewall/router) should not also be a file storage/server device.
I would stop using pfsense if this was built in, talk about a security nightmare.
You don't have enable the file server components … and I can see benefits for the typical home user?
However, I myself will probably not use the NAS components as I don't like placing such critical information on a WAN facing device.
As for ZFS, can't that be put into pfSense independent of FreeNAS? ZFS is just a file system no?
-
This will never be built in, and is highly unlikely to be added as a package. It just does not make sense to put a role with known security issues onto an edge firewall. And if it exists, people will do that even though they are guided not to.
If absolutely require a NAS and pfSense on the same hardware, virtualize it.
-
Perhaps it would be beneficial to explain my setup a little. I have 4 pfsensei, all virtual. Two of them provide redundant, failover, QOS'd internet gateway/firewall/multi-lan router. These two do exactly what a security device should, and that's NOTHING except the single security intensive task for which it was purposed.
Separately, I have two other pfsensei that run networking services. DHCP, DNS, radius, and a few incidentals for the multiple LANs that the other two route and firewall for. These two systems are behind a secure firewall, and also have their own internal firewall. I would consider these secondary system as a candidate for hosting additional file services as well. web server, WINS server, and a couple others which belong in each LAN, but do not belong on the edge device.
Furthermore, virtualizing a full fledged NAS service (Providing large scale data storage to the network) is a VERY BAD idea, especially for home users as it requires expensive special hardware to do it properly.
-
As for ZFS, can't that be put into pfSense independent of FreeNAS? ZFS is just a file system no?
As I pointed out for the general case, this is another instance of replication of code and labour. FreeNAS already has this fully fleshed out and working. It would be better for everyone to use the existing single working codebase (Fewer bugs, less chance for security related bugs to creep in).
Replication of Code/Functionality and diverging developer bases are one of the few problems still plaguing free software today. It's exactly that attitude that's contributing to the problem.
-
A security device (firewall/router) should not also be a file storage/server device.
However, a file storage/server device should most definitely be a security device.
I would stop using pfsense if this was built in, talk about a security nightmare.
Obviously you didn't read the entirety of my post. I clearly thing that by default, none of the NAS stuff should be installed on a router, and none of the router stuff on a NAS device, but available through the package system and developed atop a strong common base
-
A security device (firewall/router) should not also be a file storage/server device.
However, a file storage/server device should most definitely be a security device.
Absolutely not.
A security device should not be accessible by end users. Your NAS is a file server, and is protected by a firewall to ensure that only the traffic you want to reach it is allowed through to that zone. You may also have user level access on the NAS itself tied in with an LDAP server, this is to prevent users from attempting to authenticate directly to the NAS.
Of course I'm coming at this from a commercial POV and not home user, but the basis for that is still the same.
I would stop using pfsense if this was built in, talk about a security nightmare.
Obviously you didn't read the entirety of my post. I clearly thing that by default, none of the NAS stuff should be installed on a router, and none of the router stuff on a NAS device, but available through the package system and developed atop a strong common base
If you want it as a package… Go for it! Start coding... :)
-
developed atop a strong common base
If you want it as a package… Go for it! Start coding... :)
It's not just that I believe everything should just be a package. There needs to be a single unified base upon which all packages are built. Common to the two largest projects that share a large set of features and requirements. The greatest benefit is to be seen by merging of developer base and reduced lines of total code. Simply adding features to one or the other as packages almost completely mitigates the greatest strengths of the concept of a merger.
-
Why FreeNAS? Why not NAS4Free?
-
Why FreeNAS? Why not NAS4Free?
I'm most familiar with FreeNAS, and I know it to be generally accepted to be the "best" freebsd/pf NAS solution.
If NAS4Free developers want to get in on the whole PFSense+FreeNAS Integration to make it into a PF4NAS mega-conglomerate, there's no reason even more experienced developers wouldn't improve the overall end user experience and contribute to feature maturity, security, and polish
-
There's some general concepts that all suggest this is a bad (dangerous) idea:
-
Security vs. Convenience. They're inversely related. If people want more convenience, usually security is then sacrificed, and vice versa. By incorporating more roles onto a security appliance, it's increasing the convenience; as a result, security is decreased.
-
Attack Surface. By adding more roles, you only dramatically increase the attack service of the device, server, or appliance. Something that is a specialist then becomes a generalist. We're adding more windows and doors to the house, making it easier for just one of them to be compromised and an attacker to gain entry and own the entire box.
-
Security by Isolation concept.
NAS is a storage device, usually for personal, private, or sensitive information. Even for a home user, the data includes personal documents, finances, family photos and videos. Putting those on a a perimeter/edge device such as a router or firewall is putting all that precious data closer to the Internet, when it should be the opposite: protected and as internal as possible from the WAN.
Heck, one could argue that even pfSense with a ton of packages installed is "too much" of an all-in-one solution, for convenience. Traditional firewall, proxy, content filter, IDS/IPS, DNS, DHCP, VPN endpoint, RADIUS. Some have these roles all on separate devices.
It seems OK to me to harden each server however, including NAS. Host-based firewall like FreeBSD's pf running on FreeNAS or Suricata running on a server. I mean, all our Windows devices have a basic host-based firewall enabled, Linux has iptables, etc. So it's fine to have host-based firewalls running on a NAS appliance and other servers, but something with a role of firewall/router should really be as isolated and simple as possible to reduce attack surface.
-
-
"Furthermore, virtualizing a full fledged NAS service (Providing large scale data storage to the network) is a VERY BAD idea, especially for home users as it requires expensive special hardware to do it properly."
What? I run my pfsense virtual - seems so do you, so you think it ok to turn it into a NAS - so then what it shouldn't be a vm then?
A NAS is network attached storage - what would be full fledged vs say not full fledged? What OS you use to provide access to your storage seems irreverent , be it freenas, nas4free, unraid, openfiler, windows anything, etc..
As to special expensive hardware? Again pure poppycock.. My very reasonable priced N40L provides me both my router via vm, and my nas - currently just windows 7 running drivepool from stablebit to make it easier to share out multiple drives as one share vs having to raid them in anyway, etc. This currently provides my network with 6+ TB which can easily expand to 16 in the same box by just plugging in the drives if so desired, more if I used the esata or usb connections, etc.
Anyone with the desire can bring up a very cheap a NAS be it the os is virtual, or they just buy a premade one - there are plenty of OS'es out there that are designed to be NASes - I don't see a reason to try and combine a nas OS with my edge router/firewall..
-
Furthermore, virtualizing a full fledged NAS service (Providing large scale data storage to the network) is a VERY BAD idea, especially for home users as it requires expensive special hardware to do it properly.
Perhaps you could elaborate on that. What sort of performance do you require that can't be achieved by a virtalised solution? It seems there are plenty of pfSense users doing exactly that, running it as a VM together with a NAS VM, and seeing good results.
Steve
-
A "very bad" idea solution of using a VM is still more secure than the "atrocious horrendous ghastly abhorrent lurid terrible horrible no good very bad" idea of putting a storage server on your firewall.
If you want to shoot your own foot, we won't be handing you the gun.
-
A "very bad" idea solution of using a VM is still more secure than the "atrocious horrendous ghastly abhorrent lurid terrible horrible no good very bad" idea of putting a storage server on your firewall.
If you want to shoot your own foot, we won't be handing you the gun.
LOL.
Well said.
-
A "very bad" idea solution of using a VM is still more secure than the "atrocious horrendous ghastly abhorrent lurid terrible horrible no good very bad" idea of putting a storage server on your firewall.
If you want to shoot your own foot, we won't be handing you the gun.
I apparently haven't said loudly enough that I don't actually want any of my edge routers to also be NAS devices, and some people apparently can't read.
-
Furthermore, virtualizing a full fledged NAS service (Providing large scale data storage to the network) is a VERY BAD idea, especially for home users as it requires expensive special hardware to do it properly.
Perhaps you could elaborate on that. What sort of performance do you require that can't be achieved by a virtalised solution? It seems there are plenty of pfSense users doing exactly that, running it as a VM together with a NAS VM, and seeing good results.
Steve
Any sufficiently competent NAS needs access to RAW disks, not encapsulated disks, or disks behind a translation layer, but for optimal error recovery the NAS needs access to raw disks. This usually means direct access to the associated controller, such that either the NAS OS is on bare metal, or the Controller is passed through to the Virtual Machine. Passing the Controller through to a virtual machine requires expensive controllers, expensive motherboards, and either Limits the user to an AMD processor, or requires a Xeon processor.
As for performance, passing your NAS RAW DISKS is not about performance, it's about reliability. Certainly any data you don't care about can be on a virtualized disk NAS. Make sure you take good backups.
As for defining "Fully Fledged", a fully fledged NAS is one that's providing the primary storage for a network. The system with the massive storage that hosts the backups and large scale multimedia. The system that hosts VM images and exports them to VM hosts. It's the Fully Fledged NAS, as opposed to the lightweight NAS that someone might virtualize to provide a limited amount of space to something that needs to be available more easily. I'm picturing, well, Pictures, or a website, or a UPNP media server…
