pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162015-12-19T04:24:20ZpfSense bugtracker
Redmine pfSense - Bug #5664 (Not a Bug): Status: Dashboard traffic graphs collapse themselves, no way to ...https://redmine.pfsense.org/issues/56642015-12-19T04:24:20Zbadon _
<p>Status: Dashboard traffic graphs are collapsible, and only 1 graph is expanded when the dashboard is first loaded. Then, after some time, they collapse themselves and reset the scale and bytes/bits settings. Saving the dashboard configuration does not save the graph configuration.</p> pfSense - Feature #5663 (Rejected): Aliases should be enterable in a new-line-separated list in a...https://redmine.pfsense.org/issues/56632015-12-19T04:17:08Zbadon _
<p>If I have a list of IP addresses I want to use in an alias, the obvious way to enter them is with the URL or URL Table types, and fetch a text file, but that has some unresolved bugs:</p>
<p><a class="external" href="https://redmine.pfsense.org/issues/4766">https://redmine.pfsense.org/issues/4766</a></p>
<p>However, I have discovered accidentally that it is possible to copy and paste the list of IP address from my text file, with 1 IP on each line, into a single field of the "Host" type, and it will be automatically expanded to multiple individual fields for each IP after the page is saved. I propose that the "Host" type should be a multi-line box form field, so it's more clear that it is possible to enter IP's that way. Alternatively, another type should be created that can accommodate a text list input in as standard that is easy to compose in a text editor, and then pfSense can parse it to pull out the IP's, description, etc.</p> pfSense - Bug #5662 (Rejected): Difficult to find System: Gateways configuration pagehttps://redmine.pfsense.org/issues/56622015-12-19T04:08:38Zbadon _
<p>You would you could find the "System: Gateways" configuration page in a "Gateways" link under the "System" menu drop-down, but it's not there. I can never remember how to get to it, so I keep it open in a tab, or else I just have to click around until I stumble on it again. So, either pfSense needs a "Gateways" link in the "System" drop-down, or it should go someplace more sensible, like under the "Interfaces" drop-down. Actually, interfaces are more related to "System" than gateways are, but one thing is certain, they do fit together pretty well. It turns out I'm not the only one to be confused by something similar to this:</p>
<p><a class="external" href="https://redmine.pfsense.org/issues/5495">https://redmine.pfsense.org/issues/5495</a></p>
<p>I suggest that maybe routing, gateways, and interfaces can go together in their own drop-down. Whatever the outcome, it should be consistent. For a page titled "System: Gateways", but not be available under the "System" menu, is inconsistent.</p> pfSense - Bug #5661 (Rejected): Gateways should be able to use the same alternative monitor IPhttps://redmine.pfsense.org/issues/56612015-12-19T03:08:04Zbadon _
<p>In "System: Gateways: Edit gateway", if you enter an alternative monitor IP that is also configured for another gateway, pfSense refuses it with the following error message:</p>
<p>The following input errors were detected:<br />The monitor IP address "xxx.xxx.xxx.xxx" is already in use. You must choose a different monitor IP.</p>
<p>Sometimes I want to use the same monitor IP for various reasons, and this should not be prevented. IF there is a technical reason why it might not be recommended, that can be explained, but it should still allow me to use whatever I want to use. One reason I want to be able to use the same monitor IP is so I can gauge the performance of different internal network segments at a glance on the status page.</p>
<p>See also:</p>
<p><a class="external" href="https://redmine.pfsense.org/issues/1189">https://redmine.pfsense.org/issues/1189</a></p> pfSense - Bug #4766 (Resolved): "URL Table (IPs)" and "URL (IPs)" do not work when text file is h...https://redmine.pfsense.org/issues/47662015-06-16T16:55:49Zbadon _
<p>I ran into this problem on a fresh DVD install of pfSense. An automated upgrade did not experience this problem. On this page:</p>
<p><a class="external" href="https://192.168.1.1/firewall_aliases.php?tab=all">https://192.168.1.1/firewall_aliases.php?tab=all</a></p>
<p>"URL (IPs)" does not work at all, and it gives this error:</p>
<p>The following input errors were detected: You must provide a valid URL. Could not fetch usable data from 'https://192.168.1.1/some_file.txt'.</p>
<p>"URL Table (IPs)" is accepted by pfSense, but it does not load the actual IP's, and they will not show up in mouse hover on firewall rules page, and they will not actually function either.</p>
<p>If I remember correctly, when I tried to load the backup config XML file from the upgraded machine to the fresh-install machine, it appeared to accept the settings, but failed to actually function. Both machines are the same models, and they have identical hardware.</p> pfSense - Bug #3865 (Rejected): With explicit block-everything rule in firewall it incorrectly bl...https://redmine.pfsense.org/issues/38652014-09-15T17:50:49Zbadon _
<p>With no rules, the pfSense firewall blocks everything by default (default config includes pass-everything rules). Those default blocks are not logged, so to put blocks in the log for further study, it is necessary to add a block-everything rule with the option selected to "Log packets that are handled by this rule". Correct me if I'm wrong, but I believe that normally the firewall only blocks LAN to WAN communication, and LAN to LAN is ignored. If that is correct, then it is probably a valid bug for the firewall to block LAN to LAN DHCP broadcast 0.0.0.0 and 255.255.255.255. That bug has caused a log noise problem, described here:</p>
<p><a class="external" href="https://forum.pfsense.org/index.php?topic=81090.0">https://forum.pfsense.org/index.php?topic=81090.0</a></p>
<p>I'm not 100% convinced that is a valid bug, if (#1) there are a plethora of other possible "special" IP's that depend on network configuration, and are not the responsibility of pfSense to handle as special cases. Another example of such an IP is NetBIOS that is used by Microsoft Windows OS's broadcasted to 192.168.1.255. I decided to report this as a bug despite that because (<a class="issue tracker-1 status-3 priority-4 priority-default closed parent" title="Bug: Gateway not added when switching from DHCP to static (Resolved)" href="https://redmine.pfsense.org/issues/2">#2</a>) DHCP and DHCP the 2 broadcast IP's are a universal standard that nearly all networks use, which makes it much more important than any other "special" IP, and thus a candidate for handling with a default configuration in pfSense.</p>
<p>So, to save the devs some mental energy, there are 2 easy options to close this bug immediately (described above too):</p>
<p>1. It is resolved as INVALID because pfSense isn't responsible for handling special IP's.<br />2. It is resolved as WONTFIX because DHCP is important as a standard, but not important enough for a default configuration intended solely to address a minor logging noise problem.</p>
<p>On the other hand, if it is decided that this is a valid bug and DHCP is important enough for default configuration in pfSense, then:</p>
<p>3. Add default configuration features (like a checkbox and/or firewall rule) to pfSense that cause standard DHCP IP's to be ignored by the firewall. This might also require features to allow unusual configurations, if they are not in pfSense already.</p>
<p>I set the priority of this as "Very low" because it causes no major difficulties, and it is easy to workaround, as described here:</p>
<p><a class="external" href="https://forum.pfsense.org/index.php?topic=81090.msg446829#msg446829">https://forum.pfsense.org/index.php?topic=81090.msg446829#msg446829</a></p>
<p>I put this report in the "Logging" category because noise in firewall logs are the only problems that are caused by this issue, and they could be suppressed there. However, it's possible the issue should be fixed in a different component of pfSense, like in the "Rules/NAT" category if:</p>
<p>1. The workaround ends up being used as the fix like the "Default allow LAN to any rule".<br />2. A default rules checkbox similar to the checkboxes for "Block private networks" and "Block bogon networks" in "Interfaces: WAN" (also appears on the "Firewall: Rules" page).<br />3. The "Anti-Lockout Rule" added by a checkbox in "System: Advanced: Admin Access".</p>
<p>I skimmed through a quick search for previously reported issues, but I may have overlooked something:</p>
<p><a class="external" href="https://redmine.pfsense.org/projects/pfsense/search?issues=1&q=0.0.0.0">https://redmine.pfsense.org/projects/pfsense/search?issues=1&q=0.0.0.0</a><br /><a class="external" href="https://redmine.pfsense.org/projects/pfsense/search?issues=1&q=255.255.255.255">https://redmine.pfsense.org/projects/pfsense/search?issues=1&q=255.255.255.255</a></p>
<p>Sorry for using the Bugzilla resolution status terminology (WONTFIX, etc). I'm not familiar with Redmine, and I don't have permissions to view the form field with possible bug resolution options.</p> pfSense - Bug #3820 (Resolved): Interface mismatch dialog terminology prompts to click "Save" whe...https://redmine.pfsense.org/issues/38202014-08-20T23:58:23Zbadon _
<p>When restoring a configuration backup to a machine with slightly different interfaces, a dialog prompts the user to assign them properly to WAN and LAN roles (etc) before the backup restoration is complete and pfSense reboots. The dialog terminology differs from what is actually presented to the user because it prompts to click "Save" when the user finishes interface assignment, but the actual button text says "Apply changes". The "Save" terminology should be replaced with the "Apply changes" terminology, which is used throughout the rest of pfSense's management and GUI features.</p> pfSense - Bug #3819 (Resolved): Firewall Rule Basics documentation dangerously misleadinghttps://redmine.pfsense.org/issues/38192014-08-20T23:23:57Zbadon _
<p>On this page:</p>
<p><a class="external" href="https://doc.pfsense.org/index.php/Firewall_Rule_Basics">https://doc.pfsense.org/index.php/Firewall_Rule_Basics</a></p>
<p>It says:</p>
<p>"The default on all interfaces is to deny traffic, and only what is explicitly allowed via firewall rules will be passed.</p>
<p>Which is misleading without further explanation. It needs to be clarified that the default out-of-the-box configuration of pfSense includes rules that explicitly allow all traffic to pass, so to deny traffic, those rules must be disabled or deleted. This detail is critical in applications where data leaks could be catastrophic, like the use case described here:</p>
<p><a class="external" href="https://www.livebusinesschat.com/smf/index.php?topic=5410.0">https://www.livebusinesschat.com/smf/index.php?topic=5410.0</a></p>
<p>I could fix this myself, but I don't have a wiki account and I'm not sure how to get one. There are other problems on that page that could benefit from some clarification, but none of them are urgent like this issue is.</p>
<p>Here's a permalink to the page described in this report:</p>
<p><a class="external" href="https://doc.pfsense.org/index.php?title=Firewall_Rule_Basics&oldid=5437">https://doc.pfsense.org/index.php?title=Firewall_Rule_Basics&oldid=5437</a></p> pfSense - Bug #3818 (Resolved): Gateway status terminology is inconsistent when it is "pending" o...https://redmine.pfsense.org/issues/38182014-08-20T04:31:32Zbadon _
<p>On the dashboard Gateways widget a status of "unknown" will be shown, typically when a gateway is disconnected.</p>
<p>On the "Status: Gateways" page, "pending" will be shown:</p>
<p><a class="external" href="https://192.168.1.1/status_gateways.php">https://192.168.1.1/status_gateways.php</a></p>
<p>A single terminology should be chosen, to avoid misunderstandings or miscommunication problems. I've attached screenshots to show the bug in action.</p> pfSense - Bug #3604 (Rejected): Traffic shaper wizard rules can't be deletedhttps://redmine.pfsense.org/issues/36042014-04-16T02:25:27Zbadon _
<p>Here:</p>
<p><a class="external" href="https://192.168.1.1/firewall_shaper_wizards.php">https://192.168.1.1/firewall_shaper_wizards.php</a></p>
<p>I first tried to use the "Single Wan multi Lan" wizard, but it just kept saying "You do not have X of local interfaces!", and it doesn't matter what number I put in for X. I'm using a typical LAN --> pfSense --> WAN configuration (this may be a separate bug). I then tried the "Single Lan multi Wan" wizard, which allowed me to proceed. It didn't produce the result I was hoping to get (everything slowed to 15 KB/s), so I deleted the new stuff it added to this page:</p>
<p><a class="external" href="https://192.168.1.1/firewall_shaper.php">https://192.168.1.1/firewall_shaper.php</a></p>
<p>I then reset the states table but that did not work. I then rebooted, and that did not work either. I performed a backup here:</p>
<p><a class="external" href="https://192.168.1.1/diag_backup.php">https://192.168.1.1/diag_backup.php</a></p>
<p>I examined the XML file it produced, and I found this near the bottom, which probably should not have been there after the new traffic shaper config stuff was deleted:</p>
<p><ezshaper><br /> <step1><br /> <numberofconnections>1</numberofconnections><br /> </step1><br /> <step2><br /> <downloadscheduler>PRIQ</downloadscheduler><br /> <conn0uploadscheduler>PRIQ</conn0uploadscheduler><br /> <conn0upload>2</conn0upload><br /> <conn0uploadspeed>Mb</conn0uploadspeed><br /> <conn0download>450</conn0download><br /> <conn0downloadspeed>Kb</conn0downloadspeed><br /> <conn0interface>wan</conn0interface><br /> </step2><br /> <step3><br /> <provider>Generic</provider><br /> </step3><br /> <step4><br /> <enable>on</enable><br /> <bandwidthunit>%</bandwidthunit><br /> <address>192.168.1.1</address><br /> <bandwidth>15</bandwidth><br /> </step4><br /></ezshaper></p>
<p>I tried manually deleting that section and then restoring the only the "Traffic Shaper" "area", but it complained that it couldn't locate the correct tag. Then, I tried replacing the section with an <ezshaper/> self-closing tag in the XML file, and that worked. However, the bandwidth was still throttled back to 15 KB/s. I've run out of ideas at this point, but I think I've isolated the bug(s) enough that they can be repeated. Let me know if you need more info. I've saved the XML backup file, and I can post more data from it if necessary.</p>
<p>I searched the site for other bugs using the phrase "traffic shaper wizard", but I did not find anything like what I've written above:</p>
<p><a class="external" href="https://redmine.pfsense.org/projects/pfsense/search?issues=1&offset=20120412105431&q=traffic+shaper+wizard">https://redmine.pfsense.org/projects/pfsense/search?issues=1&offset=20120412105431&q=traffic+shaper+wizard</a></p>
<p>Let me know if the "You do not have X of local interfaces!" issue is a separate bug, and I'll post it. Otherwise, I'm going to assume for now that it's related to this bug, but I'm just making an arbitrary decision about it without actually knowing.</p>
<p>I posted this bug as "Normal" priority, but I suspect it might be worthy of an upgrade.</p> pfSense - Bug #3222 (Resolved): Firewall URL table aliases "Update Freq." has no unitshttps://redmine.pfsense.org/issues/32222013-09-22T06:33:13Zbadon _
<p>In firewall_aliases_edit.php on line 503, find:</p>
<p>$update_freq_str = gettext("Update Freq.");</p>
<p>and change it to:</p>
<p>$update_freq_str = gettext("Update days");</p>
<p>"days" are the units in a dropdown menu, from 1 to 128 days. I learned the units were days from Bug <a class="issue tracker-1 status-7 priority-4 priority-default closed" title="Bug: Unnecessary fields in firewall aliases edit page (Needs Patch)" href="https://redmine.pfsense.org/issues/2685">#2685</a>: Unnecessary fields in firewall aliases edit page. Replacing "Freq." with "days" puts units on the values in the dropdown, and its 1 character shorter! It's also translatable, searchable, etc. "Freq" and similar abbreviations are unnecessary, and as useless and annoying as abbreviating "abbreviation" with "abbr", as found in some paper dictionaries. If you want to make these form fields luxurious, I suggest changing line 503 to one of the following:</p>
<p>$update_freq_str = gettext("Days to update");</p>
<p>$update_freq_str = gettext("Update in days");</p>
<p>$update_freq_str = gettext("Fetch every (days)");</p>
<p>$update_freq_str = gettext("Update every (days)");</p>
<p>$update_freq_str = gettext("Update time in days");</p>
<p>$update_freq_str = gettext("Update time (days)");</p>
<p>$update_freq_str = gettext("Update frequency in days");</p>
<p>$update_freq_str = gettext("Update frequency (days)");</p>
<p>$update_freq_str = gettext("Update interval in days");</p>
<p>$update_freq_str = gettext("Update interval (days)");</p>
<p>$update_freq_str = gettext("Update schedule in days");</p>
<p>$update_freq_str = gettext("Update schedule (days)");</p>
<p>Of course, a better solution would be to not have a huge list of day numbers from 1 to 128, and instead have a more flexible and standard FreeBSD crontab format with the following fields:</p>
<p>minutes hours day-of-the-month month day-of-the-week</p>
<p>Described here:</p>
<p><a class="external" href="http://www.freebsd.org/doc/handbook/configtuning-cron.html">http://www.freebsd.org/doc/handbook/configtuning-cron.html</a></p>
<p>Then, virtually anyone's needs can be served. I like having simple fields for people who don't want to read documentation about how to interpret crontab fields, so having a basic setting dialog with only minutes, hours, and days ought to be sufficient for most people. I think I would prefer that being implemented first.</p>
<p>Does anyone choose a number of 128 days? I'd bet my left arm that no one has ever needed exactly 128 days to update their alias URL table. Anyone who needs to update such information is likely to prefer that it gets updated as frequently as possible. In that case, a maximum frequency of 1 day could be unsatisfactory for nearly everyone. For myself, I would like an update frequency of 1 to 15 minutes.</p>