pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162016-06-17T17:34:02ZpfSense bugtracker
Redmine pfSense - Feature #6500 (New): Should be a way to determine which packages are available without ...https://redmine.pfsense.org/issues/65002016-06-17T17:34:02ZB. Derman
<p>Since one or more packages are often a "show-stopper" requirement for pfSense users, there should be a way to authoritatively determine what packages are currently available/supported via the pfSense web site -- ideally, for all releases, minimally for the current release.</p>
<p>E.G., perhaps the generation of such a page could be added to the build/release tools or, alternatively, porting pfSense's packages pages to run on the pfSense site could provide the current-release info.</p> pfSense - Feature #4646 (New): Recover valuable vertical screen real estate in dashboardhttps://redmine.pfsense.org/issues/46462015-04-20T19:46:20ZB. Derman
<p>Vertical screen real estate tends to be quite valuable.</p>
<p>The dashboard page uses about 1/2" at the top of the page to show the controls for configuring the dashboard widgets.</p>
<p>Since one seldom updates the dashboard widgets, it would make more sense -- and recover the vertical screen space -- to show the widget-configuration controls at the bottom of the page.</p>
<p>In general, the pfsense_ng and pfsense_ng_fs themes could make much better use of vertical screen real estate by narrowing the gap between the "header" and "right" sections and by reducing the vertical whitespace between the "pgtitle" and the form sections.</p> pfSense - Bug #4640 (Resolved): "Disable Cisco Extensions" change toggles "Auto-exclude LAN addre...https://redmine.pfsense.org/issues/46402015-04-19T20:30:45ZB. Derman
<p>After updating from 2.2.1 to 2.2.2, in VPN -> IPsec -> Advanced Settings, the check-box setting for "Disable Cisco Extensions" now toggles whatever the setting was for "Auto-exclude LAN address" and the checkbox for "Auto-exclude LAN address" ignores any attempts to set it on it's own.</p>
<p>Note that the "Auto-exclude LAN address" setting is reversed from whatever it was previously (i.e., from the v2.2.1 setup) whenever the "Disable Cisco Extensions" is reversed -- i.e., depending upon the "Auto-exclude LAN address" setting inherited from v2.2.1, the "Auto-exclude LAN address" checkbox will either always be the same as the "Disable Cisco Extensions" setting or it will always be the opposite of the "Disable Cisco Extensions".</p>
<p>(Suggestion: "Affected Architecture" settings should be checkboxes, perhaps each paired with a "not tested" option)</p>
<p>This issue affects at least amd64 and i386.</p> pfSense - Bug #4604 (New): NTP time server entries may or may not work, depending upon interfaces...https://redmine.pfsense.org/issues/46042015-04-13T02:43:26ZB. Derman
<p>The attached PDF (NTP.pdf) shows the following:</p>
<p>- 2 time-server entries: time.apple.com and another pfSense box (in that order)</p>
<p>- select both WAN and LAN interface OR select neither interface:<br /> + other pfSense box is always status "Unreach/Pending" <br /> + time.apple.com works</p>
<p>- select only LAN interface:<br /> + other pfSense box works<br /> + time.apple.com is always status "Unreach/Pending"</p>
<p>- select only WAN interface:<br /> + other pfSense box is always status "Unreach/Pending" <br /> + time.apple.com works</p>
<p>I didn't capture the screenshots, but if you reverse the order of the 2 time-server entries, it also reverses the working vs. "Unreach/Pending" status, given the same interface selection(s).</p>
<p>I have a multi-LAN, multi-WAN config with only the LAN interfaces selected and a single time.apple.com time-server entry, and that works fine.</p>
<p>Another simple LAN/WAN box also has only the LAN interface selected and a single time.apple.com time-server entry, and that works fine -- but on that system, the LAN interface appears first in the list ... so the bug appears to be associated with the order of the selected entries in the interfaces list.</p>
<p>(In the attached file, the single-digit at to top of the screenshot associates configs with status/results)</p> pfSense Packages - Bug #4426 (Resolved): NUT fails to start or restart until NUT's settings are (...https://redmine.pfsense.org/issues/44262015-02-13T21:26:46ZB. Derman
<p>Since updating NUT to 2.6.5_1 pkg/2.0.4, I'm finding that NUT won't start on a pfSense reboot. Pressing a "restart service" button via the services page won't start NUT nor will the following code:<br />---<br />require_once("service-utils.inc");</p>
<p>if (is_service_enabled('nut') && !is_service_running('nut')) {<br /> start_service('nut');<br />}<br />---</p>
<p>The NUT status panel will indicate that "nut is enabled but the service is not running" (wording paraphrased from memory).</p>
<p>In order to get NUT to run, again, I need to save the settings (no changes, just resave 'em).</p>
<p>To make matters worse, restarting various other services (e.g., an OpenVPN server) will kill NUT and it won't restart.</p>
<p>Watching things, I can see that a service "stop" is issued for NUT ... and then it's done! Seems that the only way to restart NUT is to save the NUT settings.</p>
<p>This all started when I updated to pfSense 2.1.5 and inherited the current NUT package version. Previously was running pfSense 2.1.4 and (IIRC) a slightly earlier version of the NUT package.</p>
<p>I'm willing to troubleshoot this issue (I done the basics like reboot and reinstalled the package), but could use a more advanced "getting started" pointer (yes, I see the irony of that).</p>
<p>FYI, when they're all running, I have the following services:<br />---<br />apinger<br />avahi<br />bsnmpd<br />dhcpd<br />dnsmasq<br />ntpd<br />nut<br />openvpn<br />openvpn<br />openvpn<br />openvpn<br />openvpn<br />racoon<br />---</p> pfSense - Bug #3488 (Resolved): Deleting an interface doesn't delete associated shaper queueshttps://redmine.pfsense.org/issues/34882014-02-25T18:47:00ZB. Derman
<p>I'd defined a PRIQ shaper setup (via the wizard) on a 2 LAN, 1 WAN (with 4 CARP VIPs, no fail-over/syncing) then changed the queues to FAIRQ and added additional queues for a total of 7 per interface (works quite well, BTW -- my ISP doesn't support burst rates).</p>
<p>Later, when deleting one of the LAN interfaces, only the applicable LAN entry was deleted from the shaper queue-tree and the deleted LAN's queues were not deleted and were attached to the remaining LAN's tree, such that the remaining LAN ended up with a duplicate/second set of associated queues.</p> pfSense - Feature #3473 (Resolved): Allow configuration of OpenVPN keepalivehttps://redmine.pfsense.org/issues/34732014-02-19T03:17:42ZB. Derman
<p>The keepalive option is always added to an OpenVPN server configuration.</p>
<p>There are many scenarios where this is not wanted and will prevent the required behavior. In my case, when working with iOS VPN on demand rule-driven behavior, the keepalive had to be removed (by commenting out line 453 in openvpn.inc).</p>
<p>What's even worse is that, with the keepalive option configured, you can't even add options such as ping, ping-exit and inactive (i.e., via OpenVPN's "Advanced configuration") because the server fails to start when you do, citing a conflict with the keepalive option.</p>
<p>I'd suggest that the keepalive option should be an optional item configured via the GUI. A more complete/useful strategy would be to allow configuration of all of the following via the GUI:<br />- keepalive & both time parameters (should be mutually exclusive with ping/ping-exit)<br />- ping with time parameter<br />- ping exit with time parameter<br />- inactive with time parameter<br />along with a checkbox-type option to also push any of these to the client.</p> pfSense - Bug #3472 (Resolved): "Diagnostics -> Table -> [large table]" won't show table contentshttps://redmine.pfsense.org/issues/34722014-02-19T03:02:20ZB. Derman
<p>Attempting view, via "Diagnostics -> Table -> [applicable large table]", the contents of a large URL table (alias) generates an empty page with no error, etc.</p>
<p>E.G., I find that a 70K-entry table is able to be displayed but a 100K-entry table is not. I tested this with both Safari and Firefox on a system with 16 GB of memory, so it appears to be a pfSense/lighttpd issue.</p>
<p>The underlying files and table do seem to be intact and it's just the display of the info that's at issue.</p> pfSense - Bug #3471 (Resolved): Attempting to load an empty URL table (alias) causes an errorhttps://redmine.pfsense.org/issues/34712014-02-19T02:55:03ZB. Derman
<p>Attempting to load an empty URL table (alias) causes an error.</p>
<p>If a table download fails and/or results in an empty file, it'd be better if the the update process recognizes this.</p>
<p>In the case of such a failure, it may be better to leave the previous file/table intact, instead of killing the previous table and possibly losing important rules.</p> pfSense - Bug #3470 (Resolved): IPSec VPN not recognizing alternative IP namehttps://redmine.pfsense.org/issues/34702014-02-19T02:44:21ZB. Derman
<p>Using a self-created/signed CA (created via pfSense's nice Certificate Manager), I created a server and user certificate with a common name of gateway.mydomain.com and subject alternative IP names for the 1 real WAN IP and the 4 CARP VIP WAN IPs.</p>
<p>When used with an OpenVPN config where the server was indicated only via the WAN IP address (a static CARP VIP and the "local" directive used to bind OpenVPN to it), the certificate worked fine but when used with an equivalent IPSec config, the error "WARNING: unable to get certificate <abbr title="3">CRL</abbr> at depth:0" (and depth:1) is logged and connections fail.</p>
<p>Generating another set of certificates having only the applicable IP address as the common name worked around the problem (and verified that the issue was non-recognition of the alternative IP name).</p> pfSense - Bug #3469 (Resolved): rc.update_urltables can skip doing a required updatehttps://redmine.pfsense.org/issues/34692014-02-19T02:33:24ZB. Derman
<p>/etc/rc.update_urltables often skips doing a required update ...</p>
<ul>
<li>/etc/rc.update_urltables runs at 12:30 PM each day and processes url-table files after a "random" 5-60 second delay (I assume to help prevent thousands of servers from firing off at the same time)</li>
</ul>
<ul>
<li>the variable delay plus the actual file processing adds some number of seconds so timestamps on updated files in /var/db/aliastables/ are from 12:30:05 to 12:31:00 (or later if the server delivering the file is slow and/or the file is large)</li>
</ul>
<ul>
<li>when the "process_alias_urltable" subprogram (in /etc/inc/pfsense-utils.inc) checks to determine whether an update is required, it requires the /var/db/aliastables/ file's timestamp to be more than ('number of days set for "Update Freq." in the URL Table alias' times '86400 seconds' [1 day])</li>
</ul>
<ul>
<li>if the variable (5-60 second) delay in starting the update plus the processing time (in /etc/rc.update_urltables) was longer during the previous update than in the current update, the "Update Freq. * 86400 seconds" will be larger than the difference between the current date/time and the timestamp on the file from the previous update and no update will occur</li>
</ul>
<ul>
<li>a simple way to fix this is to bias the "should we update" check in /etc/inc/pfsense-utils.inc by the maximum delay introduced by /etc/rc.update_urltables, plus some allowance for file-processing time -- e.g.:</li>
</ul>
<p>In /etc/inc/pfsense-utils.inc change line 2016 from<br /><code> || ((time() - filemtime($urltable_filename)) > ($freq * 86400))</code><br />to<br /><code> || ((time() - filemtime($urltable_filename)) > (($freq * 86400) - 90))</code></p>
<p>The 90-second bias allows another 30 sec. for any downloading/processing to complete, over and above the 60-second variable delay imposed by /etc/rc.update_urltables and it's still shorter than the 1-day minimum update frequency so it shouldn't break anything else.</p> pfSense - Bug #3468 (Resolved): Wording fixhttps://redmine.pfsense.org/issues/34682014-02-19T02:13:51ZB. Derman
<p>In /etc/rc.update_urltables change line 43<br />from<br /> log_error("{$argv<sup><a href="#fn0">0</a></sup>}: {$t['name']} does not need updated.");<br />to<br /> log_error("{$argv<sup><a href="#fn0">0</a></sup>}: {$t['name']} does not need updating.");</p> pfSense - Bug #3467 (Resolved): pfTop [Queue] doesn't show P/S or B/Shttps://redmine.pfsense.org/issues/34672014-02-19T02:11:08ZB. Derman
<p>"Diagnostics -> pfTop [Queue]" doesn't show P/S or B/S (running command-line pftop followed by left-arrow does show P/S & B/S).</p> pfSense - Bug #3465 (New): Editing Traffic Shaper queues causes status_queues.php errorhttps://redmine.pfsense.org/issues/34652014-02-19T01:53:35ZB. Derman
<p>Editing traffic shaper queues (Firewall -> Traffic Shaper -> By Interface) can cause "php: /status_queues.php: XML error: no altqstats object found!" to be logged if "Status -> Queues" is running or is run too soon after committing changes (presumably because the queues are temporarily undefined ... i.e., the error logging corresponds with "pfctl -s queue" temporarily indicating that no queues exist.</p>
<p>If this is "as designed" (due to reloading), then perhaps a note could be appended to the error message, itself -- e.g., XML error: no altqstats object found! (can be caused by traffic shaper changes being reloaded).</p>
<p>This sent me on a "wild goose chase" 'til I figured out what was happening (on the positive side, it was an "expanded learning experience!").</p> pfSense Packages - Bug #2892 (Resolved): "pfblocker_Range2CIDR" function yields erroneous results...https://redmine.pfsense.org/issues/28922013-03-20T02:30:30ZB. Derman
<p>E.G. the file<br /><a class="external" href="http://list.iblocklist.com/?list=bt_ads&fileformat=p2p&archiveformat=gz">http://list.iblocklist.com/?list=bt_ads&fileformat=p2p&archiveformat=gz</a><br />on 2013-Mar-18 has/had an entry (on line 165):<br />---<br />ADC01/ADC06 ads:61.135.131.31-61.135.131.34</p>
<p>Using the "pfblocker_Range2CIDR" function contained in /usr/local/pkg/pfblocker.inc in pfBlocker v1.0.2 to convert the IP address range:<br />---<br />61.135.131.31 to 61.135.131.34</p>
<p>yields a CIDR represenation of:<br />---<br />61.135.131.27/30</p>
<p>but 61.135.131.24/30 "expands" to the 4 incorrect IP addressses:<br />---<br />61.135.131.24<br />61.135.131.25<br />61.135.131.26<br />61.135.131.27</p>
<p>... whereas, using the "ip_range_to_subnet_array" function contained in /etc/inc/util.inc in pfSense v2.0.2 to convert the IP address range:<br />---<br />61.135.131.31 to 61.135.131.34</p>
<p>yields CIDR represenations of:<br />---<br />61.135.131.31/32<br />61.135.131.32/31<br />61.135.131.34/32</p>
<p>which collectively "expand" to the 4 (correct) IP addresses:<br />---<br />61.135.131.31<br />61.135.131.32<br />61.135.131.33<br />61.135.131.34</p>
<p>Not sure why the existing pfSense function wasn't used, but it appears that the one in pfBlocker will, in some instances, will generate CIDRs that can cause "good guy" IPs to be blocked and "bad guy" IPs to remain unblocked. On the plus side, fixing the bug should be as easy as switching to the function supplied by pfSense.</p>
<p>Regardless, I certainly appreciate the pfBlocker package and will be sending a small donation in as soon as our PayPal account gets refilled.</p>