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 #6130 (Duplicate): Alias-table failures can easily lead to serious security deg...https://redmine.pfsense.org/issues/61302016-04-13T03:25:24ZB. Derman
<p>Failures that result in empty alias-tables being created (e.g., <a class="external" href="https://redmine.pfsense.org/issues/6119">https://redmine.pfsense.org/issues/6119</a>) or tables failing to be created (e.g., <a class="external" href="https://redmine.pfsense.org/issues/4513">https://redmine.pfsense.org/issues/4513</a>) are not detected.</p>
<p>Aliases are seriously useful in being able to define concepts and create much more "human consumable" rules. The increased clarity helps reduce complexity (well, to the User, anyway) and errors and thus aids security by helping ensure correct configurations.</p>
<p>Alias-table failures, by definition (pun intended), cause loss of functionality and, depending upon that functionality, can cause significant loss of security -- which is a prime purpose of pfSense.</p>
<p>As indicated in issue 6119, we had a device modified because of the loss of security due to this kind of failure. While it wasn't catastrophic, it easily could have been.</p>
<p>It would be much nicer (and safer) if these kind of failures were caught by pfSense. E.G., something as "simple" as warning when tables are defined (and used in a rule) but are missing or empty would really have helped with issues 6119 and 4513.</p> pfSense - Bug #6119 (Closed): Alias entry causes filterdns core dumpshttps://redmine.pfsense.org/issues/61192016-04-12T17:37:07ZB. Derman
<p>The following is with pfSense 2.2.6 release AMD64 on a Core 2 Duo 3 GHz dual-core with 4 GB ram.<br />---<br />While creating an alias containing multiple networks, I used copy/paste and (unthinkingly) pasted 18 of the 22 entries as #.#.#.0/24:</p>
<p>- the first issue is that these were all accepted without warning</p>
<p>- the second issue is that, apparently upon saving the alias definition, these were not created as though I'd selected "24" via the "CIDR" popup menu (which would have made the first issue a feature, not an issue) ... but each /24 entry was <em>expanded</em> to the 256 IPs as though I'd made the separate 256 entries for each</p>
<p>- the third issue is that, once the alias was used in a rule and the alias' table was to be created, the filterdns process was failing:</p>
<pre><code>+ pfSense fails with a "direct" alias definition with 4,612 entries (i.e., not using a URL/file-based alias)</code></pre>
<pre><code>+ during every "reload," filterdns would (seemingly, by watching top) slowly (5-15 minutes) grow in size then core-dump when it reached around 400 MB "RES"</code></pre>
<pre><code>+ during the "reload," the router is effectively "dead" (i.e., seemingly all traffic, including web-configurator, is blocked)</code></pre>
<pre><code>+ the long-lived all-blocking behavior of this issue makes troubleshooting and repair very difficult ... well, very slow, at least</code></pre>
<p>- the fourth issue -- a very serious one -- is that the failure of filterdns caused multiple tables to still be listed as present, but to have no contents (at a quick glance, it appears this is for any alias table that has one or more FQDN entry)</p>
<p>This is a serious issue because the creation of empty tables causes loss of both functionality and security. In fact, we had one device modified due to the inherent loss of security this failure caused.</p>
<p>(I selected "All" for affected version since you don't have 2.2.6 as an available selection.)</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 #4641 (Duplicate): Restored config loses IPv6 Link-Local DNS Forwarder Settingshttps://redmine.pfsense.org/issues/46412015-04-20T02:49:01ZB. Derman
<p>Restoring a config that contains selected "Services -> DNS Forwarder -> Interfaces" which are "IPv6 Link-Local" doesn't maintain those "IPv6 Link-Local" Interface selections during the restore, which can result in a DNS that doesn't function or functions very slowly.</p>
<p>I've attached two screenshots showing a config that was restored (ConfigSettings.png) and the results after restoring (RestoredSettings.png).</p>
<p>I suspect the underlying issue is also causing <a class="external" href="https://redmine.pfsense.org/issues/3802">https://redmine.pfsense.org/issues/3802</a>.</p>
<p>This issue affects at least amd64 and i386.</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 - Bug #4513 (Duplicate): Change in IP Alias name causes no tables on reboothttps://redmine.pfsense.org/issues/45132015-03-11T21:21:20ZB. Derman
<p>I've supplied 2 sanitized config files that were created as follows:</p>
<p>- restore working config (via Backup/restore page)<br />- reboot the router<br />- verify that tables were created<br />- download config (via Backup/restore page) ... this is the file "OK-config" <br />- change the IP Alias name from BEDiMacLAN1 to BEDiMacOnLAN1 (save and apply)<br />- note that no BEDiMacOnLAN1 table exists ... in my experience, this means "you're in trouble if you reboot" <br />- reboot the router<br />- verify that tables were NOT created<br />- download config (via Backup/restore page) ... this is the file "failing-config"</p>
<p>The failure occurs whether the various URL alias files are of zero size or are populated.</p>
<p>Both the production system and test systems this has been verified on are Core 2 Duo systems with 4 GB of memory. For me, this issue is 100% reproducible.</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 #4283 (Rejected): Constant cas# device timeout errors and crashes with Sun 501-6738-10https://redmine.pfsense.org/issues/42832015-01-24T19:41:31ZB. Derman
<p>Updated a copy of a working 2.1.5 production system to 2.2 and, during the boot, see constant cas2 and cas3 device timeout errors (cas1-3 interfaces are configured). Looks like yet another "ol' workhorse" NIC has been obsoleted. <sigh></p>
<p>The test system has a Intel Celeron 2.2 GHz processor. After completing a <em>very slow</em> boot (>10 minutes), if pfSense doesn't crash, it's certainly unusably slow (i.e., takes "forever" even to reconfigure -- presumably because everything's mostly blocked due to the device timeouts).</p>
<p>I'm assuming there's no hope of this getting fixed?</p> pfSense - Bug #3602 (Rejected): OpenVPN can authenticate via a broken certificatehttps://redmine.pfsense.org/issues/36022014-04-12T20:05:39ZB. Derman
<p>See bug 3470 (<a class="external" href="https://redmine.pfsense.org/issues/3470">https://redmine.pfsense.org/issues/3470</a>).</p> pfSense - Bug #3493 (Closed): mute-replay-warnings doesn't appear to workhttps://redmine.pfsense.org/issues/34932014-02-27T15:08:37ZB. Derman
<p>Have the lines</p>
<p>mute-replay-warnings;<br />verb 1;</p>
<p>as entries in the OpenVPN Advanced Configuration box, but am still getting lots of messages like the following (only IPv4 in use)</p>
<p>Feb 25 13:50:34 openvpn<sup><a href="#fn61934">61934</a></sup>: 209.121.225.198:8877 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #1 / time = (1393365006) Tue Feb 25 13:50:06 2014 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings</p>
<p>I believe the messages are actually due to the fact that neither iOS 7.0.6 nor 7.1b5 handle VPN on-demand processing properly when transitioning from WiFi to cellular. After multiple seconds worth of such failures, the server resets the connection and a successful connection follows. <sigh></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 - Bug #3481 (Needs Patch): Run-Away processing with hme NICshttps://redmine.pfsense.org/issues/34812014-02-23T03:49:29ZB. Derman
<p>Subsequent to posting an issue to the mailing list (issue documented at <a class="external" href="http://www.derman.com/pfSense-Run-Away-Issue">http://www.derman.com/pfSense-Run-Away-Issue</a>) and getting the following response from Jim Pingle (thanks, Jim):<br />---<br />Try pfSense 2.1.1. There were some issues with link cycling in certain cases that you might be hitting which were fixed on 2.1.1.<br />---<br />I did a lengthy series of tests. After still getting the same run-away behavior even after reducing the config to a level where I'd be able to send it to someone, I realized I'd not tried switching out the kind of NIC used for the WAN port (though I had tested 2 different NICs in 2 different machines).</p>
<p>Short story is that it appears to be related to using an hme NIC for a monitored interface. See the above web page for what I think I know about this issue.</p>
<p>If you're unable to replicate the issue and/or want me to try something, contact me via the contact form on our/that web site and I'll do what I can to help.</p>
<p>I made backups as I was testing so I can also get you a backup of the most-reduced config I tested.</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>