Features I'd like to see in 2.0
-
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
