Features I'd like to see in 2.0
-
I'm a new user of pfSense, I've meddled with it for 10 days, and I love it. Even though it obviously is not intended for you average consumer, I think it will benefit from some added functionality in the user-interface, changes which would make it more accessible for both Joe Average Consumer and the professional admins. I've encountered a few stumbling blocks, which pretty much every new user will, so here are my suggestions in no particular order. (I've tried to limit myself to suggestions which should be easy to implement, and follow what I think is the general direction of pfSense 2.0.)
-
Either rename the Web-configurator Anti-lockout rule to something which adequately describes it's function (which is to make a rule which allows access to all ports on the pfsense-box), or change the rule so that it only ensures access to the webconfigurator-port. (It took me needlessly long to find out that this was the reason I couldn't block particular ports on the pfsense-box.)
-
Auto-create aliases for ports, networks and gateways which are used by pfsense-components. This is to make creating firewall-rules more flexible, and to not break those rules after internal changes. (It would make development easier, as you could change a lot more of the internal configurations without breaking functionality.) This would also make configurations a lot more portable from site to site.
-
Add a cache-size option for the DNS-forwarder. This is something which pretty much every admin will want to set up. If set on auto, display the cache-size on the configuration page and/or the dashboard (like you do for the state-table.)
-
Do not allow PowerD to be checked and run when only incompatible timecounters exist on the system. This will just fill your log with useless error-messages. (I had to change boxes mid-configuration due to a hardware fault. The new box filled the log with errors due to having only the TSC timecounter.)
-
Add an option to bypass the console menu when you SSH into the box. It's just annoying having to press '8' each and every time, and to have to press CTRL-D twice to exit. (And why the heck is Shell #8 instead of #1? ;-))
-
When running pftop from the console menu, add an option to control it's arguments. (seconds, display mode, sorting etc.)
-
If at all possible, add MAC identification to the firewall, so we don't have to put pretty much every machine on a static lease. (I've read somewhere that pf supports this.)
-
Add the openvpn-client gateway(s) as selectable gateway(s) in the firewall-rules.
-
Add an "Add alias from this" button next to the red fields, so that you don't have to backtrack to the alias-page, then back to the firewall rule everytime you realise you'd better use one.
-
Add a dropdown-menu of aliases of the proper type to the the red fields.
-
More fine-grained control over the configuration backups and restores. Would be nice to restore, say, just a set of firewall rules and/or aliases.
-
Add a directory which can be included in the configuration backups, or backup a user-selectable set of files. Every user of pfsense will have to, sooner or later, add some files to the file system. It would be very nice if these could migrate in the configuration backups. (How nice it would be if pfsense could simply automatically include every file which is not part of the default install, but that I think is asking too much.)
-
When configuring an OpenVPN-client, add an option to automatically add a proper NAT-rule for the interface.
This may seem like a lot, but I believe most of these are easy changes which just build upon functionality already present, and as you can see the common themes are flexibility and portability.
If a feature I've requested above is already present, and I just haven't found it, I apologize in advance.
Let me repeat that I love pfSense, it is by far the best firewall/router distro I've ever tried. The guys behind it deserve a lot of praise. Whatever happens, good luck to all devs.
::Trym
-
-
I'm a new user of pfSense, I've meddled with it for 10 days, and I love it. Even though it obviously is not intended for you average consumer, I think it will benefit from some added functionality in the user-interface, changes which would make it more accessible for both Joe Average Consumer and the professional admins. I've encountered a few stumbling blocks, which pretty much every new user will, so here are my suggestions in no particular order. (I've tried to limit myself to suggestions which should be easy to implement, and follow what I think is the general direction of pfSense 2.0.)
Well the ship may have sailed for some of these to be in 2.0, but feature request tickets for 2.1 may be a good idea. (http://redmine.pfsense.org/)
- Either rename the Web-configurator Anti-lockout rule to something which adequately describes it's function (which is to make a rule which allows access to all ports on the pfsense-box), or change the rule so that it only ensures access to the webconfigurator-port. (It took me needlessly long to find out that this was the reason I couldn't block particular ports on the pfsense-box.)
That has always been the behavior of the anti-lockout rule, even in 1.2.x. The description could probably be amended, but it may not be a good idea to alter that default behavior at this point. People may be unknowingly relying on that rule to grant access to other services running on pfSense that they don't have explicit pass rules for (DNS forwarder, etc).
- Auto-create aliases for ports, networks and gateways which are used by pfsense-components. This is to make creating firewall-rules more flexible, and to not break those rules after internal changes. (It would make development easier, as you could change a lot more of the internal configurations without breaking functionality.) This would also make configurations a lot more portable from site to site.
That's a good idea, but probably too big to get in at this stage.
- Add a cache-size option for the DNS-forwarder. This is something which pretty much every admin will want to set up. If set on auto, display the cache-size on the configuration page and/or the dashboard (like you do for the state-table.)
That should be fairly trivial to add, but I don't recall anyone else ever really needing to adjust that value. If you open a feature request that one may make it in early if someone has a few minutes to code it up. Even better likelihood of making it in if someone provides a patch.
- Do not allow PowerD to be checked and run when only incompatible timecounters exist on the system. This will just fill your log with useless error-messages. (I had to change boxes mid-configuration due to a hardware fault. The new box filled the log with errors due to having only the TSC timecounter.)
That's a bit more complex than that. TSC may work with powerd on some hardware but not others, and timecounter quality varies widely depending on chipsets, BIOS versions, etc. There is no easy way to determine if the option should be allowed. (And the backend code would need to check it, not just the GUI, in case a config with powerd enabled was restored to hardware where powerd doesn't work properly).
- Add an option to bypass the console menu when you SSH into the box. It's just annoying having to press '8' each and every time, and to have to press CTRL-D twice to exit. (And why the heck is Shell #8 instead of #1? ;-))
Not really much of a reason to do that, though if you really want to you could just login as root and delete the "rc.initial" call from /root/.profile.
- When running pftop from the console menu, add an option to control it's arguments. (seconds, display mode, sorting etc.)
Still a bit more complex than prompting for values. If someone really wants more control it can be changed with keyboard controls once started, or drop to a shell and start it by hand.
See the INTERACTIVE MODE section of the man page (http://www.rootr.net/man/man/pftop/8)
- If at all possible, add MAC identification to the firewall, so we don't have to put pretty much every machine on a static lease. (I've read somewhere that pf supports this.)
Someone was thinking of adding that to 2.1 already, again it's too large for 2.0 at this point, unless someone puts it into a package.
- Add the openvpn-client gateway(s) as selectable gateway(s) in the firewall-rules.
Agreed, there's already a ticket open for that. Not sure if it will make 2.0 though.
http://redmine.pfsense.org/issues/904- Add an "Add alias from this" button next to the red fields, so that you don't have to backtrack to the alias-page, then back to the firewall rule everytime you realise you'd better use one.
Might be handy, but a bit trickier to code than it might seem at first. Probably would have to wait for 2.1 unless some code appears.
- Add a dropdown-menu of aliases of the proper type to the the red fields.
That could get out of hand very quickly with a large number of aliases. Autocomplete seems to work fine, but perhaps some other indicator other than the red background is needed to cue users that they need to start typing the name.
- More fine-grained control over the configuration backups and restores. Would be nice to restore, say, just a set of firewall rules and/or aliases.
Sort of related to this: http://redmine.pfsense.org/issues/939
Beyond restoring whole sections, it probably wouldn't be feasible. It would be a lot of extra code to go through and let you pick and choose which rules or aliases to restore out of the whole list.- Add a directory which can be included in the configuration backups, or backup a user-selectable set of files. Every user of pfsense will have to, sooner or later, add some files to the file system. It would be very nice if these could migrate in the configuration backups. (How nice it would be if pfsense could simply automatically include every file which is not part of the default install, but that I think is asking too much.)
There is a backup package already that does this.
- When configuring an OpenVPN-client, add an option to automatically add a proper NAT-rule for the interface.
Might be nice, sort of related to the OpenVPN ticket I linked to above. It would just need a checkbox to include it in automatic outbound NAT. (Manual would of course still need to be done by hand)
This may seem like a lot, but I believe most of these are easy changes which just build upon functionality already present, and as you can see the common themes are flexibility and portability.
Some may be easy, others are easy to think of but not easy to code. :-)
Generally good ideas, but due to 2.0 being mostly feature frozen it's probably too late to get a lot of that in. If we keep adding things, it will never get to RC stage, and thus to a Release.
-
For openvpn gateways, you can just assign the openvpn client interfaces and they will show up as dynamic gateways.
-
How about multiple IP addresses per NIC, like in Windows or Linux or most modern operating systems?
-
How about you stop trolling in forums and learn what pfSense is capable of.
-
How about multiple IP addresses per NIC, like in Windows or Linux or most modern operating systems?
IP Alias VIPs (and CARP VIPs if they're in the same subnet) both work for that. IP aliases are new in the GUI for 2.0, CARP VIPs have been there forever. You could always hack an IP alias into the config, but now it's really supported.
-
I'm not sure where "trolling the forums" is coming from. I'm sorry that my comment came off as critical. It wasn't intended to be.
First of all, I love the pfSense system, including the user interface. You guys have done a magnificient job on it. Please take this as "an idea" if you can call it that.
I think the intuitiveness for the multiple IPs (or IP alias) could be enhanced slightly.
Right now, you have the main IP address under "Interfaces." If you want to add an additional IP address, you have to go under a different menu heading, "Firewall" then choose "Virtual IPs," then "IP alias," and configure it there. Maybe just putting a link over to that page from the Interface page in question would do it. Something that indicates to the busy sysadmin in effect, "Hey, this is something else this awesome system does." Maybe on the WAN page, there could be a link to "IP aliases for this interface," for example. Something like that.
Thanks.
-
That is completely unrelated to the issues being discussed in this thread, which is part of why Ermal said what he said.
The IP Alias VIPs are added the way other VIPs are added, and it is consistent with the rest of the UI. Adding multiple IPs on the interface page would not be consistent. It's a bikeshed discussion, and still not relevant to the issues raised in this thread.
-
Jimp, thank you very much for a thorough and detailed response, I didn't even expect anyone to reply to this. I'm very pleased you actually thought some of the ideas are worthy of implementation at some point.
As for 1) I agree it would be foolish at this point to alter the default behaviour, as it might break some things, so I guess a big fat warning is required. "WARNING: This will create an invisible rule allowing access to all ports of PfSense. If you wish to block access to certain ports of PfSense, you need to disable this rule."
Or even better… when you are in fact making a rule to block a port on the PfSense-box, it should be easy for the firewall-configurator php-code to realize the rule won't work, and pop up a warning: "This rule will not work unless you disable the Anti-lockout rule." (Only when the Anti-lockout rule is ticked, of course.)
Actually, I wouldn't mind if both were present.
As for 3) I agree this is actually a non-issue, after having read up on dnsmasq a little. Even on a box with not much RAM, it defaults to a cache of 10000, which is the max hardcoded limit at this point. That many entries will never be used unless you're an ISP or in front of more than 200 clients, because Dnsmasq respects the upstream TTL, which most set to a couple of minutes. I had hoped there would be a way to override the TTL and actually use all that cache, but the only thing you can override is the clients' TTL. (Which I've done.) However, since the cache-size IS configurable (as well as many other parameters) I see no reason for it NOT being configurable if the web-config either.
As for 4) you say "There is no easy way to determine if the option should be allowed." I agree that it is very hard to check if you should be allowed to tick the box or not. However, PowerD itself should be responsible for shutting down. It produces the error-messages, so it should realise it won't work, and quit trying ad infinitum. It is very unlikely that after having tried changing frequency 1000 times, that it will suddenly work on try 1001. As most other components, it should simply exit with a message to the log detailing why.
-
Thanks for the tip, I'm a BSD-noob, and wasn't aware of this. Done. (I still think there should be a checkbox under general setup though.)
-
Right now I do this: Double-click my Putty-shortcut,then: (8<enter>)pftop -s 1<enter>ooooo7. This is my preferred pftop view, on this current setup. At another location, my preferred view would probably be different. It isn't really any harder than adding a input box somewhere in the general setup is it? A text-string which will be appended to the pftop command. (Mine would be "-i -s 1 -o sport -v <something>")
Don't get me wrong, this is a very minor quibble. Just a bit of spit and polish. (I guess anyone familiar with BSD would just write a shell-script and be done with it. Getting there.)
-
The reason I suggested the drop-down box to begin with is that right now, the red-fields are so narrow I almost never can see what autocomplete is suggesting. I have aliases like NATPMP_PORTS and NATPMP_DESTINATIONS, BYPASS_VPN_CLIENTS, BYPASS_VPN_DESTINATIONS etc. Only the first six or seven letters would be visible in the suggestion box. The whole thing is just a bit awkward when you have a lot of aliases.
-
I apologize, bad research on my part.
Again, thanks for the response.
::Trym</something></enter></enter>
-
-
As for 1) I agree it would be foolish at this point to alter the default behaviour, as it might break some things, so I guess a big fat warning is required. "WARNING: This will create an invisible rule allowing access to all ports of PfSense. If you wish to block access to certain ports of PfSense, you need to disable this rule."
The "invisible" part is implied in the text already, but perhaps not in an obvious-enough way. :-)
Actually what would be nicer is to make the rule show up in the rule list but greyed out, like the bogons/rfc rules do.
Or even better… when you are in fact making a rule to block a port on the PfSense-box, it should be easy for the firewall-configurator php-code to realize the rule won't work, and pop up a warning: "This rule will not work unless you disable the Anti-lockout rule." (Only when the Anti-lockout rule is ticked, of course.)
Actually, I wouldn't mind if both were present.
That seems a bit over-engineered and prone to error. Not sure I'd like that (but it's debatable).
As for 3) I agree this is actually a non-issue, after having read up on dnsmasq a little. Even on a box with not much RAM, it defaults to a cache of 10000, which is the max hardcoded limit at this point. That many entries will never be used unless you're an ISP or in front of more than 200 clients, because Dnsmasq respects the upstream TTL, which most set to a couple of minutes. I had hoped there would be a way to override the TTL and actually use all that cache, but the only thing you can override is the clients' TTL. (Which I've done.) However, since the cache-size IS configurable (as well as many other parameters) I see no reason for it NOT being configurable if the web-config either.
I swear there was a ticket out there to add a bunch of dnsmasq's options but I can't find it now. Many of them would be handy for some people and not terribly complex to add. Would be a good easy project for someone looking for something to do after the 2.0 release.
As for 4) you say "There is no easy way to determine if the option should be allowed." I agree that it is very hard to check if you should be allowed to tick the box or not. However, PowerD itself should be responsible for shutting down. It produces the error-messages, so it should realise it won't work, and quit trying ad infinitum. It is very unlikely that after having tried changing frequency 1000 times, that it will suddenly work on try 1001. As most other components, it should simply exit with a message to the log detailing why.
Unfortunately, powerd is all from FreeBSD, so we don't really have that much control over its behavior. For me on ALIX it tries once, fails, and dies. I haven't ever seen it try repeatedly in that way. The proper thing to do there would be to install FreeBSD 8.1-STABLE on the same hardware, reproduce it, and file a PR with FreeBSD so it can be fixed upstream.
- Thanks for the tip, I'm a BSD-noob, and wasn't aware of this. Done. (I still think there should be a checkbox under general setup though.)
Since we have the user manager now, it would be better for that to be a per-user checkbox instead of a global option.
- Right now I do this: Double-click my Putty-shortcut,then: (8<enter>)pftop -s 1<enter>ooooo7. This is my preferred pftop view, on this current setup. At another location, my preferred view would probably be different. It isn't really any harder than adding a input box somewhere in the general setup is it? A text-string which will be appended to the pftop command. (Mine would be "-i -s 1 -o sport -v <something>")
Don't get me wrong, this is a very minor quibble. Just a bit of spit and polish. (I guess anyone familiar with BSD would just write a shell-script and be done with it. Getting there.)</something></enter></enter>
Seems really awkward to control a shell menu option from the GUI config. Debatable, I suppose, but since you are one extra keystroke away from a shell and that isn't something most users are likely to even know how to configure, it doesn't seem like it would be worth the effort.
- The reason I suggested the drop-down box to begin with is that right now, the red-fields are so narrow I almost never can see what autocomplete is suggesting. I have aliases like NATPMP_PORTS and NATPMP_DESTINATIONS, BYPASS_VPN_CLIENTS, BYPASS_VPN_DESTINATIONS etc. Only the first six or seven letters would be visible in the suggestion box. The whole thing is just a bit awkward when you have a lot of aliases.
When you autocomplete, at least for me, it shows a drop-down list of all matching entries that is not limited by the size of the box. I have no trouble picking the right entry.
-
"Actually what would be nicer is to make the rule show up in the rule list but greyed out, like the bogons/rfc rules do."
Could not agree more. For some reason I assumed this rule being invisible was set in stone. Showing it in the list will remove any and all confusion.
"Since we have the user manager now, it would be better for that to be a per-user checkbox instead of a global option."
Again, 100% agree, having this as a per-user setting is very sensible.
"When you autocomplete, at least for me, it shows a drop-down list of all matching entries that is not limited by the size of the box. I have no trouble picking the right entry."
This had me puzzled. It annoyed me to no end the last time I tried. I don't have access to the original box I setup, so I just installed pfsense in a virtual machine and a client in another. It works in firefox now, so I can only assume it was either a plugin in the original client I used, or that is was just a temporary fluke in some of the builds that cause this. (IE6 hates the PF 2 interface, but you already know that I presume.)
Thanks for the feedback, I appreciate it. I will come back to this in a couple of weeks, look at the state of things then, and add the proper tickets/request to the proper places.
::Trym
-
"Actually what would be nicer is to make the rule show up in the rule list but greyed out, like the bogons/rfc rules do."
Could not agree more. For some reason I assumed this rule being invisible was set in stone. Showing it in the list will remove any and all confusion.
I just checked in that change, so it should be in future snapshots.
"Since we have the user manager now, it would be better for that to be a per-user checkbox instead of a global option."
Again, 100% agree, having this as a per-user setting is very sensible.
Added as a feature request with a "future" target.
http://redmine.pfsense.org/issues/997
