Packages wishlist?
-
I just think it's time for packages to follow suit.
You mean change current package categories to a more specif one?
for example:
change dansguadian from Services to proxy filter
change squidguard from Network Management to proxy filter
change squid from Network to proxy serveror create tabs for each category
-
He's talking about the actual menu entries… Services > Proxy Filter (squidguard), Services > Proxy Filter (squid) and so on.
-
In an ideal world, we might have freely definable, customizable menus, but that's a huge change and may make into something like pfSense 3.0 but it's certainly not around the corner or easy to do.
In the second best of worlds, we'd have submenus for specific categories, e.g.
Services > DNS > Server
Services > DNS > Forwarder
Services > DNS > Dynamic DNSThat would solve the issue with long drop-down menus and makes things easy to find, although the former has been somewhat defused with the recent addition of scrollable menus.
Of course, that's a non-trivial change to the UI which some people may not even agree with, even though.
So in the third best of worlds, we simply name things in such a way that they fall in place within a linear menu structure in logical groups. The pfSense base system does that already fairly well; notice e.g. how nicely the DHCP and most of the DNS items fall into place.
He's talking about the actual menu entries… Services > Proxy Filter (squidguard), Services > Proxy Filter (squid) and so on.
Exactly. Because that's a very easy and quick change and it solves 90% of what the more complex solutions would achieve for almost zero development effort. All it needs is a naming convention that people adhere to.
-
In an ideal world, we might have freely definable, customizable menus, but that's a huge change and may make into something like pfSense 3.0 but it's certainly not around the corner or easy to do.
This is not feasible from my point of view, I think there is no reason why we should customize the feel and looks of a tool. I think the effort should be more or less in a making rules and adjustments of the network
-
In an ideal world, we might have freely definable, customizable menus, but that's a huge change and may make into something like pfSense 3.0 but it's certainly not around the corner or easy to do.
This is not feasible from my point of view, I think there is no reason why we should customize the feel and looks of a tool. I think the effort should be more or less in a making rules and adjustments of the network
Feasible or not, it's not what I suggested we do, certainly not anytime soon.
I do however take a bit issue with the direction of the argument. It strikes me a bit as if we were talking about screwdrivers and you'd say:
"I think there is no reason why we should create ergonomic handles on a tool. I think the effort should be more or less in making durable and non-slip screwdriver tips."The point is, a good screwdriver has both, it may even have a ratcheting handle, in which you can customize the interface, depending on whether you want to screw a screw into or out of something…
-
way offtopic
I just mentioned that does hammer work better if you can read hammer from the hammer itself?!? and have changeable plates on that so you can localize your hammer text. Like the shape itself isn't enough.
-
way offtopic
I just mentioned that does hammer work better if you can read hammer from the hammer itself?!? and have changeable plates on that so you can localize your hammer text. Like the shape itself isn't enough.
No, but pfSense is a tool box, not a single tool. And a well organized and labeled toolbox is a lot more efficient to use, than a box where things are wildely out of order and you have to go hunting for the tools.
Also, not everyone is a master craftsman. You want to be able to have the apprentice fetch an auger then you must assume that he may not know how an auger looks like, but if he can read and the toolbox is organized and labeled properly, he will likely fetch the auger, even if he's never seen one before.
Further, since this is a thread about a wishlist, I think it's perfectly fine that I wish what I consider relevant. It's not like I'm dictating features, I just take the liberty to wish for what makes my work easier.
-
IMHO pfsense pkg developers' energy should be focused on making sure that the handful of "Tier 1" packages (e.g. Snort, routing daemons for BGP/OSPF, Varnish/haproxy and Squid) work flawlessly.
Btw I am not sure that trying to glue together packages like Squid + Dansguardian / SquidGuard etc will work as well as in the various commercial UTMs.
Finally, since IMHO pfsense isn't very well suited for SOHO environment (unless one really wants to learn a great deal in the process), it doesn't matter very much if pfsense is always checking to make sure that a user doesn't do the wrong thing (e.g. resolving conflicts between packages Quagga-OSPF vs OpenOSPF etc).
-
Hi,
I would like to see Salt as a package. It would be convenient to be able to remotely configure and manage a bunch of pfSense installations from one central point.
There's already a Salt package available in FreeBSD ports:
http://docs.saltstack.org/en/latest/topics/installation/freebsd.html
-
Finally, since IMHO pfsense isn't very well suited for SOHO environment (unless one really wants to learn a great deal in the process), it doesn't matter very much if pfsense is always checking to make sure that a user doesn't do the wrong thing (e.g. resolving conflicts between packages Quagga-OSPF vs OpenOSPF etc).
You make it sound like learning something were a bad thing. pfSense works just fine in my SOHO setup, as a matter of fact, I switched to pfSense because nothing else out there (except maybe Vyatta, but I don't like their ever more proprietary approach) could do the job I want at anywhere near justifiable costs, because cost is a massive factor in a SOHO office.
Arguing against built-in conflict resolution is like saying circular saws are for professionals only, and therefore they don't need finger guards. We might as well do away with the anti-lockout rule, etc.
IMO any good product minimizes the error potential, that's the whole point of having a user interface in the first place, otherwise, we all could just edit config files with vi. -
In my case I would love to see nginx as package. It can be used as reverse proxy, web server, SSL-offloading for HAProxy (replacement for stunnel), etc.. It is light in resource usage and does great work.
-
Could anyone please create a Zabbix 2.0 Proxy package upgrade? Since there are a lot of improvements in the latest Zabbix release, It would be great if we could use it. Thank you! :-*
-
i'd really like to see some kind of clientless ssl vpn. similar to what sslexplorer or adito is/was. the new astaro UTM has a html 5 based clientless vpn.be great if could link to freeradius also.
-
If an up-to-date OSS project exists for such a thing, I'm sure it could be looked into, so long as the requirements are not crazy (like Adito's need for Java)
There really is no such things as a "clientless" VPN, it may use Java or hook into the browser, but it's still a client.
-
I would like a clickable whois search on the alerts or blocked tab in snort.
Greets, Judex
-
At first many thanks to Ermal and others for great job with Snort package. I have one little wish to help my everyday job. We have pfsense in our network. This time it is securing 5 LAN networks and we have hundreds of users in our networks. Because our company have very tight internet rules we need to Snort our LAN side traffic also and block offenders in LAN networks. Problem is that when snort blocks out a user (or IP-address) there is no information send to user about that. Traffic just ends. Next thing is the user picks up the phone and calls us and reports internet failure. Is there any chance to get a popup window, redirection or at least error page to user that tells reason for blocking? It also would help us to fix problems in rules also. The page should say for example:"You are blocked out: #REASON#". Of cause there should be enable/disable tag and selection for LAN-networks also :)
-
@NG:
At first many thanks to Ermal and others for great job with Snort package. I have one little wish to help my everyday job. We have pfsense in our network. This time it is securing 5 LAN networks and we have hundreds of users in our networks. Because our company have very tight internet rules we need to Snort our LAN side traffic also and block offenders in LAN networks. Problem is that when snort blocks out a user (or IP-address) there is no information send to user about that. Traffic just ends. Next thing is the user picks up the phone and calls us and reports internet failure. Is there any chance to get a popup window, redirection or at least error page to user that tells reason for blocking? It also would help us to fix problems in rules also. The page should say for example:"You are blocked out: #REASON#". Of cause there should be enable/disable tag and selection for LAN-networks also :)
Well you need to put some funding to this since its not that easy.
-
Hi Ermal! I can talk with my bosses about funding. I can't promise anything, I'm just a small Network Engineer :) About the idea, I was just wondering if it's possible to do that Squidguard style. Comparing clients IP and Snort blocklist. If there's a match then redirect to info page. Actually maybe this can be done in Squid or Squidguard or other external process, so the Snort is not part of this. In this case Snort is just offering some information to other processes and they do the rest..
-
openDNS dnscrypt proxy for encryption of dns traffic from pfsense box to opendns servers
-
ndpmon (the IPv6 ARPWatch) should be interesting as PFSense is the router.
http://www.freebsdsoftware.org/net-mgmt/ndpmon.html
http://ndpmon.sourceforge.net/index.php
