pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162016-03-24T13:34:58ZpfSense bugtracker
Redmine pfSense Packages - Bug #6023 (New): Traffic Shaper (pfsense 2.3) Suricata V3.0 Inline Mode Operationhttps://redmine.pfsense.org/issues/60232016-03-24T13:34:58ZG. Howard Krauss
<p>Gentleman:</p>
<p>Bill Meeks asked that I describe the issue. I have Pfsense 2.3 (beta) installed with the latest version of Suricata V3.0 installed. I have been using the traffic shaper to reduce bufferbloat. This is accomplished with CODELQ. I works fine with Suricata V3.0 in the legacy mode. But when Suricata V3.0 is placed in the inline mode the traffic shaper now longer works. I have been using dslreports online tool for testing bufferbloat. Additionally, when I try to remove the traffic shaper (still in the inline mode) the system freezes. A reboot is required to return to operation. There is some strange interaction between the traffic shaper and suricata V3.0 inline mode.</p> pfSense Packages - Bug #5751 (New): SquidGuard target categories not saved when long "Domain List...https://redmine.pfsense.org/issues/57512016-01-10T08:55:57Z- -protodev@gmx.net
<p>I created a new entry in the 'Target categories' tab and tried to copy/paste the testfile which is appended into the 'Domain List' field.<br />After saving and reopening the newly created target category, the 'Domain List' field is empty.</p>
<p>Splitting the testfile up into 6 target categories (app. 10000 domains each) works just fine.</p>
<p>The bug appeared on pfSense 2.2.6 (i386)</p> pfSense - Bug #4680 (New): DHCP relay does not work with DHCP server on other end of OpenVPN tunnelhttps://redmine.pfsense.org/issues/46802015-05-05T18:55:30ZPer von Zweigbergkpvz@itassistans.se
<p>It is currently documented at <a class="external" href="https://doc.pfsense.org/index.php/DHCP_Relay">https://doc.pfsense.org/index.php/DHCP_Relay</a> that DHCP Relays don't work over IPsec tunnels. However, it turns out they don't work over OpenVPN tunnels either.</p>
<p>From my observations (with packet filtering completely disabled to rule that out as a cause):</p>
<p>DHCP query gets broadcast by client.<br />DHCP query gets sent on as unicast to DHCP server by relay.<br />DHCP server responds with unicast to DHCP relay address<br />DHCP relay DOES NOT forward packet on to client! (Expected behaviour: It should do this)</p>
<p>Tracing this back, it would appear that this is an old bug that's been known since at least 2007, as discussed on this mailing list post: <a class="external" href="https://lists.isc.org/pipermail/dhcp-users/2007-February/002787.html">https://lists.isc.org/pipermail/dhcp-users/2007-February/002787.html</a></p>
<p>Right now, the only available workarounds as far as I know are:</p>
<p>1. Use something else to do DHCP relay (such as your switch, or a different pfSense box that doesn't run OpenVPN)<br />2. Use a local DHCP server rather than running DHCP relay</p> pfSense - Bug #4467 (New): Traffic Graphs shows wrong throughput when traffic shaping enabledhttps://redmine.pfsense.org/issues/44672015-02-23T17:31:43ZJoe Laffeyjoe@thestable.tv
<p>When I enable traffic shaping with the wizard the traffic graph is incorrect. It is showing much lower throughput than is actually occurring. I am testing this by remotely downloading a file from a local HTTP server on the DMZ. The traffic graph for the DMZ is correct, but the WAN outbound is showing about 1/3 or so of the actual throughput. The same holds true if I make an outbound connection and upload a file, for instance.</p>
<p>Otherwise the shaping seems to be working OK. We have dual WAN and three LAN (LAN, DMZ, WIFI - which is handled by its own wifi router, not a wifi card in the pfsense machine).</p>
<p>I tried both HFSC and Priority queuing on all interfaces.</p>
<p>The throughput of individual hosts/ips shows up correctly on the traffic graph page. It is just the total throughput of the WAN interface that is being displayed incorrectly it is incorrect both on the dedicated traffic graph page, and in the widget version of the traffic graph on the default page (assuming you enable the traffic graph widget). On the Traffic Graph page you can see that the total of all the ips traffic adds up to more than the reported total value.</p>
<p>The SNMP output for the WAN interface is also wrong (which is the most annoying part as I have this in my shell's screen hard status line, and reference it constantly.)</p>
<p>The rrd graphs seem to indicate the correct throughput.</p>
<p>The WAN2 interface, and the LAN, DMZ, and WIFI interfaces all display the correct throughput.</p>
<p>No clue it is makes a difference, but the WAN interface is the second interface (if2 via SNMP). It goes LAN, WAN, DMZ, WIFI, WAN2 in order.</p> pfSense - Bug #3706 (New): Permission order affects default page on limited accounts, but can't r...https://redmine.pfsense.org/issues/37062014-06-11T09:11:35ZTrel Swebmaster@krahs-emag.com
<p>1. Make an account<br />2. Assign dashboard permission<br />3. save<br />4. Assign reboot permission<br />5. save<br />6. log in with that account<br />Result: Dashboard comes up with ability to access the reboot page</p>
<hr />
<p>1. Make an account<br />2. Assign reboot permission<br />3. save<br />4. Assign dashboard permission<br />5. save<br />6. log in with that account<br />Result: Reboot page comes up instead of dashboard</p>
<p>If this behavior is correct, there needs to be a way to re-order permissions to allow the dashboard to come up as the default page, otherwise, this behavior itself is likely incorrect.</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 - Bug #3411 (New): Interfaces and statistics dashboard widgets very slow with large numbe...https://redmine.pfsense.org/issues/34112014-01-24T02:09:51ZChris Buechlercbuechler@gmail.com
<p>The interfaces and statistics dashboard widgets cause the dashboard to take minutes to load where a system has a large number of interfaces (hundreds). It would be nice to speed that up at some point if possible. Work around is to not use those widgets on systems with large numbers of interfaces.</p> pfSense - Bug #3404 (New): DHCP Server Fails to Start on Interfaces that are Slow to Come Online ...https://redmine.pfsense.org/issues/34042014-01-22T10:12:42ZJason Crowleyjcrowley@in-kc.com
<p>When the services_dhcpd_configure() function is called during boot, it will skip interfaces that are not fully online. If all dhcpd-enabled interfaces are not online, dhcpd will fail to start. If only some of the interfaces are online, it will start but not serve dhcp on the slow-to-start interfaces.</p>
<p>The place where we've been able to reproduce this consistently is OpenVPN interfaces that have dhcpd enabled.</p>
<a name="Background-Information"></a>
<h2 >Background Information<a href="#Background-Information" class="wiki-anchor">¶</a></h2>
<p>OpenVPN's native IP-address allocation system does not work with dnsmasq to register clients' IP addresses in DNS. To work around this limitation, we build an OpenVPN tunnel that allows us to obtain IP addresses from pfSense's DHCP server. The dhcpd instance will then go through the normal process to ensure that the client's IP is registered with dnsmasq.</p>
<a name="Platform-Affected"></a>
<h2 >Platform Affected<a href="#Platform-Affected" class="wiki-anchor">¶</a></h2>
<p><strong>2.1-RELEASE</strong> We're using amd64, but I expect it affects all processor architectures.</p>
<a name="Steps-to-Reproduce"></a>
<h2 >Steps to Reproduce<a href="#Steps-to-Reproduce" class="wiki-anchor">¶</a></h2>
<ol>
<li>Configure an OpenVPN Server in tap mode. Ensure you've set the following parameters.
<ul>
<li>Device Mode: tap</li>
<li>IPv4 Tunnel Network: <blank>
<ul>
<li><em>We want dhcpd, not openvpn assigning IP addresses.</em></li>
</ul>
</li>
<li>Advanced configuration: server-bridge
<ul>
<li><em>This enables the DHCP broadcast traffic to traverse the tunnel to the dhcpd instance on the pfSense OpenVPN interface</em></li>
</ul>
</li>
</ul>
</li>
<li>Configure the OpenVPN interface with a static IP address.</li>
<li>Configure and enable a DHCP server on the OpenVPN interface.</li>
<li>Reboot.</li>
<li>Log in via SSH and execute the following command.<br /><pre>
# ps -axww | grep dhcpd
...
46118 ?? Ss 0:00.09 /usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid em0 em2
</pre></li>
<li>Note that the last two arguments in the dhcpd command line above are the interfaces for dhcpd to listen on. There is not an OpenVPN interface (ovpns1) there. If you try to acquire a DHCP lease over an OpenVPN connection, you will get no response.</li>
<li>Restart dhcpd via the web gui Services page.<br /><pre>
# ps -axww | grep dhcpd
...
69734 ?? Ss 0:00.00 /usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid em0 em2 ovpns1
</pre></li>
<li>Note that the ovpns1 interface is now in the command line. You can now acquire a DHCP lease through your OpenVPN tunnel.</li>
</ol>
<a name="Recommended-Solution"></a>
<h2 >Recommended Solution<a href="#Recommended-Solution" class="wiki-anchor">¶</a></h2>
<p>One of my coworkers (Micah Mitchell) is working on a simple solution that will add about 10 lines of code to the services_dhcpd_configure() function. This code will check each interface configured with a DHCP server to see that it is up before starting dhcpd. If an interface is not up, it will sleep for 1 second and loop for up to 10 seconds before moving on.</p>
<p>Our initial testing shows this code resolves the problem on the pfSense instances we've tested it on. During boot, we see a two-second delay while services_dhcpd_configure() waits for interfaces to come online prior to launching dhcpd. Expect the code to be submitted within the next day or two.</p> pfSense - Bug #3358 (New): new version of <include_file> is not required during reinstall_allhttps://redmine.pfsense.org/issues/33582013-12-06T12:48:48ZRenato Botelhorenato@netgate.com
<p>When an outdated version of a package is installed and pfSense is updated, it will call pkg_reinstall_all() on next boot.</p>
<p>This function calls uninstall_package() what will call require_once() for files on tag <include_file> of the old version of the package</p>
<p>After this install_package() will be called, and will try to require_once() the new version of include_file, what will not be done</p>
<p>This can cause issues on the installation of new version of the package.</p> pfSense - Bug #3326 (New): IPv6 only PPPoE connectionhttps://redmine.pfsense.org/issues/33262013-11-18T09:37:08ZTadeusz Magura-Witkowskiteeed@na1noc.pl
<p>pfSense version: 2.1-RELEASE<br />I have discovered that it is impossible to have IPv6 only PPPoE connection. PPP keeps restarting.</p>
<p>Nov 18 16:34:43 ppp: caught fatal signal term</p> pfSense - Bug #2367 (New): display negate rules in firewall_rules.php and evaluate when addedhttps://redmine.pfsense.org/issues/23672012-04-11T00:02:00ZChris Buechlercbuechler@gmail.com
<p>the fact the negate policy routing rule isn't shown is bad as it has lead to unintended consequences (ends up passing traffic people don't realize is passed because it's hidden). They should be shown as a grayed out auto-added rule, similar to block private/bogon.</p>
<p>Also need to look at when and how that rule is automatically added. In some circumstances it can allow more traffic than the user intends, such as: <br /><a class="external" href="http://forum.pfsense.org/index.php/topic,48143.0/topicseen.html">http://forum.pfsense.org/index.php/topic,48143.0/topicseen.html</a></p> pfSense - Bug #2335 (New): IGMPProxy and CARP Results in System Instability Upon Reboot https://redmine.pfsense.org/issues/23352012-04-02T14:23:11ZJ Ptheprez@theprezonline.com
<p>This scenario was replicated on 3 PCs with various network cards on 2.01.</p>
<p>Enabling a CARP interface on a box with IGMPProxy running and receiving multicast traffic results in the box becoming unstable upon reboot. Once rebooted, the interfaces will come up briefly and eventually cease to pass traffic/assign IPs via DHCP. If rebooted a subsequent time, the same scenario repeats itself.</p>
<p>Repeated by:</p>
<p>Using 3 different machines, 2 i386 and 1 ia64 with various branded NICs.</p>
<p>Public IP passed to WAN<br />192.168.0.0/24 on LAN<br />UDP traffic permitted on WAN via Rule: UDP * * 224.0.0.0/4 * * NONE<br />On LAN - Default allow rule was edited, advanced options selected to allow IP with options - enable Multicast</p>
<p>CARP:</p>
<p>Firewall -> Virtual IP<br />Type = CARP<br />Interface = WAN<br />IP Address = Public /32<br />Virtual IP Password = whatever<br />VHID 1<br />Save</p>
<p>SSH int PFSense router to ping the upstream router using:<br />ping -c1 -S <CARP IP> <UPSTREAM IP></p>
<p>So that the upstream 2Wire router detects the new virtual MAC address.</p>
<p>Reboot computer</p>
<p>About 5 minutes into working it will freeze and cease to pass traffic.</p> pfSense - Bug #2308 (New): HFSC WebUI doesn't check for "Bandwidth" settinghttps://redmine.pfsense.org/issues/23082012-03-23T13:11:08ZOliver Loch
<p>Hi,</p>
<p>I configured pfSense todo some QoS. To get everything "firsthand" I used the HFSC module.</p>
<p>When configuring a HFSC queue you can add values for the "Service Curve" as shown in the attached screenshot.</p>
<p>If you add the realtime settings m1,d,m2 or just m2, and don't put anything inside the "Bandwidth"-field above, you can save and reload those settings.</p>
<p>After the reload you get error messages that say something like this:</p>
<p>php: : New alert found: There were error(s) loading the rules: pfctl: the sum of the child bandwidth higher than parent "root_em1" pfctl: linkshare sc exceeds parent's sc /tmp/rules.debug:47: errors in queue definition pfctl: the sum of the child bandwidth higher than parent "root_bridge1" pfctl: linkshare sc exceeds parent's sc /tmp/rules.debug:59: errors in queue definition pfctl: the sum of the child bandwidth higher than parent "root_bridge1" pfctl: linkshare sc exceeds parent's sc /tmp/rules.debug:60: errors in queue definition pfctl: Syntax error in config file: pf rules not loaded The line in question reads [ the sum of the child bandwidth higher than parent "root_em1" pfctl]:</p>
<p>This comes from the fact, that the empty "Bandwidth"-field results in a pf rule like this:</p>
<pre><code>queue wweb on em1 qlimit 500 hfsc ( realtime (10%, 10000, 5%) )</code></pre>
<p>which doesn't hold the "bandwidth"-statement and results in an error like:</p>
<p>[2.0.1-RELEASE][<a class="email" href="mailto:root@pfSense.localdomain">root@pfSense.localdomain</a>]/tmp(4): pfctl -nf rules.debug<br />pfctl: the sum of the child bandwidth higher than parent "root_em1" <br />pfctl: linkshare sc exceeds parent's sc<br />rules.debug:47: errors in queue definition<br />pfctl: the sum of the child bandwidth higher than parent "root_bridge1" <br />pfctl: linkshare sc exceeds parent's sc<br />rules.debug:59: errors in queue definition<br />pfctl: the sum of the child bandwidth higher than parent "root_bridge1" <br />pfctl: linkshare sc exceeds parent's sc<br />rules.debug:60: errors in queue definition<br />[2.0.1-RELEASE][<a class="email" href="mailto:root@pfSense.localdomain">root@pfSense.localdomain</a>]/tmp(5):</p>
<p>That's because the system assumes "100%" bandwidth if the option is omitted.</p>
<p>The errors on line 59 and line 60 are from those lines:</p>
<p>59: queue lweb on bridge1 qlimit 500 hfsc ( realtime (10%, 10000, 6%) )<br />60: queue lmail on bridge1 qlimit 500 hfsc ( realtime 5% )</p>
<p>Same shit, different pile ...</p>
<p>It would be nice to ask the user what todo, or to just set "m2" as the "Bandwidth" of the queue as one can use "m2" alone for realtime settings without a peak.</p> pfSense - Bug #2138 (New): RRD Wireless graph broken in BSS modehttps://redmine.pfsense.org/issues/21382012-01-23T17:19:08ZChristian Borchertccb056@gmail.com
<p><a class="external" href="http://forum.pfsense.org/index.php/topic,45194.0.html">http://forum.pfsense.org/index.php/topic,45194.0.html</a></p>
<p>I am using pfSense 2.0.1 amd64 with an Atheros card (D-Link DWA-556) in Infrastructure (BSS) mode.<br />The "Wireless" RRD graphs show no data and the numerical results are all "nan" <br />However, the Traffic, Packets, Quality, Queues, and QueueDrops graphs for OPT1 (wifi card) all show valid data.</p>
<p><img src="http://db.tt/rqTVwplz" alt="" /><br /><img src="http://db.tt/EqDJ7zve" alt="" /></p> pfSense - Bug #1675 (New): Captive portal logout problems with pop-up blockers.https://redmine.pfsense.org/issues/16752011-07-12T17:13:32ZErmal Luçieri@pfsense.org
<p>Need to change the Captive portal pop-up page to use techniques to bypass pop-up blockers.</p>