pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162015-09-01T18:42:41ZpfSense bugtracker
Redmine pfSense - Bug #5075 (Confirmed): pf errors that don't return a line number on first line don't fi...https://redmine.pfsense.org/issues/50752015-09-01T18:42:41ZChris Buechlercbuechler@gmail.com
<p>rulesets that generate errors not including the line number on the first line of the resulting output don't file a notice. For instance drop the attached into a config.</p> pfSense - Bug #4845 (Confirmed): CARP preemption doesn't switch to backup where connectivity betw...https://redmine.pfsense.org/issues/48452015-07-15T22:39:20ZChris Buechlercbuechler@gmail.com
<p>Take a basic WAN and LAN setup, one CARP IP on each interface. If WAN's NIC loses link, the secondary system takes over master status on both CARP IPs, and the primary switches to backup. Instead of losing link, sever connectivity between the two while retaining the NIC's link. The secondary sees that and takes master status on all CARP IPs. But the primary doesn't switch to backup status, so you're left with dual master, and the resulting brokenness that entails.</p>
<p>This is the same behavior as FreeBSD 8.3, 10.1, 11, and OpenBSD 5.7, so just a general issue with CARP. Problematic especially in virtualization scenarios because the VM won't lose link when the hypervisor does, leaving the network broken upon loss of connectivity on one network.</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 #4406 (Confirmed): ALTQ problems with wireless cloned interfaceshttps://redmine.pfsense.org/issues/44062015-02-11T02:10:02ZChris Buechlercbuechler@gmail.com
<p>ath(4) does have ALTQ support, but its cloned interfaces end up unable to use it.</p>
<pre>
There were error(s) loading the rules: pfctl: ath0_wlan0: driver does not support altq
</pre>
<p>If you're only using ath0, ALTQ works fine.</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 #1848 (Confirmed): Limiters after policy routing has taken place do not behave corr...https://redmine.pfsense.org/issues/18482011-09-07T02:57:53ZErmal Luçieri@pfsense.org
<p>If there are 2 WANs and the primary one fails and there are limiters configured in floating rules(after policy routing has taken place) there will be issues induced because the way limiters(dummynet) works.<br />Basically the policy routing decision will be forgotten by the path packet takes through dummynet.</p>
<p>The obvious fix is remember the policy routing decision even through this path and that will solve the problem.</p> pfSense - Bug #1186 (Confirmed): When in pure routing mode the rrd graphs are blankhttps://redmine.pfsense.org/issues/11862011-01-12T03:32:32ZErmal Luçieri@pfsense.org
<p>When the filtering is disabled the graphs have no data to graph since we switched to pf counters.<br />Probably should have both option and check if filtering is enabled or not.</p>