pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162022-04-25T09:47:09ZpfSense bugtracker
Redmine pfSense Packages - Feature #13096 (Feedback): Improve robustness of Snort Rules Update Log size l...https://redmine.pfsense.org/issues/130962022-04-25T09:47:09ZBill Meeks
<p>Change the code for truncating the Snort Rules Update Log file when it exceeds the maximum configured size to be more robust by dropping the use of <em>unlink()</em> and use the method used in the Suricata package instead.</p> pfSense Packages - Bug #13095 (Feedback): Snort VRT change in Shared Object Rules path name resul...https://redmine.pfsense.org/issues/130952022-04-25T09:43:25ZBill Meeks
<p>Apparently the Snort Vulnerability Research Team recently altered part of the path name inside the Snort Rules Update archive. This results in failure of the Snort package code to properly extract and copy the Shared Object (SO) rules when performing the periodic rules update. A portion of the long directory path in the archive was changed from "x86_64" to "x86-64" (replaced the underscore with a dash).</p> pfSense Packages - Bug #12979 (Pull Request Review): Snort Rules Update Process Using Deprecated ...https://redmine.pfsense.org/issues/129792022-03-23T14:23:01ZBill Meeks
<p>Beginning around the first of March 2022, the Snort rules update package from the Snort VRT changed the subdirectory name for the precompiled Shared Object (SO) rules, in the archive, from "FreeBSD-12" to "FreeBSD-13". The Snort rules update code in the GUI parses the current FreeBSD version from the operating system, so since pfSense is still on FreeBSD 12.3, this results in the rules update code searching for a non-existent "FreeBSD-12" subdirectory in the archive when unpacking it. Until such time as pfSense moves to FreeBSD-13, this logic needs to be changed and the subdirectory name hard-coded to "FreeBSD-13".</p> pfSense Packages - Bug #12924 (New): DNS Resolver WireGuard ACL Inconsistencyhttps://redmine.pfsense.org/issues/129242022-03-09T10:59:57ZKevin Mychal Ong
<p>Initially, I had two pfsense nodes connected via the WireGuard package. My tunnel network was 10.0.3.0/30 for p2p. I then added another pfsense node to make the topology hub and spoke. Naturally, I had to make my tunnel network larger, so I changed the WG interface subnets to /29 instead and proceeded with adding the third node. Everything is working properly except for the fact that the Unbound ACL that's created by WireGuard on the first two nodes did not change from /30 to /29. It says in the description not to touch those but I manually changed them to /29 instead just to make things consistent. However, after restarting the pfsense box, it just goes back to /30.</p> pfSense Packages - Bug #12760 (New): Link-local addresses disallowed on Wireguard interfaceshttps://redmine.pfsense.org/issues/127602022-02-06T00:46:58ZAlex Chang-Lam
<p>Wireguard supports link-local IPv6, however adding a static link-local to interfaces is not allowed, even for interfaces of type tun_wg.</p>
<p>This is particularly necessary for dn42.</p> pfSense Docs - Todo #12756 (New): Add information on correct MTU to use with WireGuardhttps://redmine.pfsense.org/issues/127562022-02-04T08:51:57ZViktor Gurov
<p><strong>Page:</strong> <a class="external" href="https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-ra.html">https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-ra.html</a></p>
<p><strong>Feedback:</strong></p>
<p>In all four Wireguard configuration recepies, there is no mention of changing the MTU and MSS values</p> pfSense - Bug #12715 (New): Long system startup time when LDAP is configured and unavailable duri...https://redmine.pfsense.org/issues/127152022-01-21T15:36:42ZChristian McDonaldcmcdonald@netgate.com
<ol>
<li>Currently if LDAP is unavailable at system startup, several LDAP queries have to timeout before the system will proceed with startup. There is no recycling of connections, so <em>n</em> LDAP queries requires <em>n</em> separate connections, and thus <em>n</em> separate timeouts. This results in a hang at startup that is several minutes long in some cases, probably dependent on the number of LDAP calls that are required (e.g. <em>n</em> * LDAP_timeout).</li>
<li>If LDAP is unavailable during system startup, the system will appear to hang at "Synchronizing user settings..." </li>
<li>This is unavoidable if LDAP connectivity relies on a VPN (e.g. IPsec, WireGuard, etc.), FRR for dynamic routes, etc...these services are started later in the startup process.</li>
<li>We should implement some sort of global state that will prevent subsequent LDAP queries if one times out during system startup, as subsequent attempts are likely to fail as well.</li>
</ol>
<p>Related to <a class="external" href="https://redmine.pfsense.org/issues/11644">https://redmine.pfsense.org/issues/11644</a></p> pfSense Packages - Bug #12608 (New): WireGuard tunnels monitored by dpinger causing system to sto...https://redmine.pfsense.org/issues/126082021-12-16T15:14:54ZChristian McDonaldcmcdonald@netgate.com
<p>Current workaround is to disable gateway monitoring on WireGuard tunnel gateways.</p>
<p>(I will be noting observations here as I unpack this)</p> pfSense Packages - Feature #12526 (New): WireGuard Widgethttps://redmine.pfsense.org/issues/125262021-11-16T14:48:56ZB. B.
<p>Hellow,</p>
<p>I want to request a feature to the WireGuard widget, probably not so important for many others.<br />Do you think it is possible to add a "Widget title" to the WireGuard widget?<br />So we can change the name of the widget :)</p> pfSense Packages - Feature #12525 (New): WireGuard Tunnel restore configurationhttps://redmine.pfsense.org/issues/125252021-11-16T14:45:43ZB. B.
<p>Hi,</p>
<p>I see the function for downloading the configuration "files" in the WireGuard - Tunnels (nice to backup the config files)<br />But it would also be nice if it was possible to restore it.<br />It would save you a lot of time if we're unlucky and messed up the tunnel/peers. :)</p> pfSense Packages - Feature #12513 (New): WireGuard Utilization Status (Beyond Active Connection)https://redmine.pfsense.org/issues/125132021-11-09T15:46:45ZJum Pers
<p>WG and pfSense are working very well together these days - thank you for the continued code and UI updates.</p>
<p>A feature that would be quite helpful on the SysAdmin side (for knowing when one can perform some client systems maintenance in scenarios where users can work whenever) is if, for both the WG Status page and (ideally) WG Widget (also), there was a set-able level (transfer threshold) that would indicate that a WG connection was actually being used rather than merely connected.</p>
<p>Perhaps this could be achieved by polling the transfer rates (RX, TX) every so many seconds (30s?) and subtracting the previous values from the present values (to see if they are above the threshold). In this way, setting a threshold for common RDP activity would provide a way of knowing whether the remote user was actively using their remote system.</p>
<p>Suggestion-wise, a colorized (green, yellow [optional: could be used for when close to threshold], red) icon, perhaps even just a small-to-medium sized (not-too-distracting) dot, to the right of the Peer name (or to the immediate right of the handshake icon if preferable) would do the trick. Or any such visual indicator.</p>
<p>Presently, it takes a lot of memorization ;) and page reloads to try to gauge which WG connections are actually being used.</p> pfSense - Todo #10199 (New): Improve Spanish translation interfacehttps://redmine.pfsense.org/issues/101992020-01-22T09:20:34ZAluisco Miguel Ricardo MastrapapfSense - Feature #9293 (New): Provide WebUI message (banner) prior to loginhttps://redmine.pfsense.org/issues/92932019-01-29T06:18:56ZRyan Haraschak
<p>While trying to deploy in govt environments, they have security guidelines (STIGs) we're required to follow. Some, as trivial as they seem, include displaying banners before logging in. I've been able to modify the html\php to meet this requirement, however, as expected, the changes are lost after an update.</p>
<p>Would it be possible to add a text entry field on the general settings page that provides a persistent webui login banner?</p>
<p>Here's an example from the <a href="https://www.stigviewer.com/stig/red_hat_enterprise_linux_6/2018-03-01/finding/V-38593" class="external">DoD RHEL STIGs</a>:</p>
<pre>
You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.
</pre> pfSense - Bug #6605 (Confirmed): rc.linkup logic issues with actions takenhttps://redmine.pfsense.org/issues/66052016-07-12T19:46:41ZChris Buechlercbuechler@gmail.com
<p>The actions taken by rc.linkup differ depending on whether the interface has a static or no IPv4 and IPv6 IP, and every other case (where either the v4 or v6 type of the interface is dynamic). <br /><a class="external" href="https://github.com/pfsense/pfsense/blob/RELENG_2_3/src/etc/rc.linkup#L70">https://github.com/pfsense/pfsense/blob/RELENG_2_3/src/etc/rc.linkup#L70</a></p>
<p>While there are no doubt some edge case reasons for that being the way it is, it's not sensible logic in general. The actions taken should be much closer to the same between them.</p>
<p>The only known problem this causes is with CARP. The interface_bring_down function removes CARP VIPs from the interface. If you have a static v4 and track6 LAN, this makes CARP get into dual master on WAN when the LAN loses link. What should happen is the CARP IP stays in INIT, which increments net.inet.carp.demotion by 240, which makes the secondary take over for the WAN VIPs. What actually happens is it increments demotion by 240, fails over to the secondary, then the VIP is deleted from the LAN on primary so demotion gets a +240 on the primary because the VIP is gone, and the primary takes back over master. Then you have dual master on WAN.</p>
<p>interface_bring_down should never be run on an interface where a CARP VIP resides to avoid this situation. It's questionable whether it's ever actually necessary or desirable when losing link on a NIC.</p>
<p>This is a potentially touchy area for regressions, so it'll need a good deal of review, testing and time to run in snapshots.</p> pfSense - Bug #5413 (Confirmed): Incorrect Handling of Unbound Resolver [service restarts, cache ...https://redmine.pfsense.org/issues/54132015-11-10T23:42:22Zky41083 -
<p>The right way to handle local DNS changes, for Unbound at least, would basically be to do the opposite of what is being done now. Rather than write to the config files and bounce the service, you would use unbound-control to tell Unbound about the local DNS changes.</p>
<p>Discussion here: <a class="external" href="https://forum.pfsense.org/index.php?topic=89589.0">https://forum.pfsense.org/index.php?topic=89589.0</a><br />Full rough draft solution here: <a class="external" href="https://forum.pfsense.org/index.php?topic=89589.msg568043#msg568043">https://forum.pfsense.org/index.php?topic=89589.msg568043#msg568043</a></p>
<p>Quick and dirty rough draft summary... doubt code syntax is even completely right (if I had more time it would be, leave it up to who codes it), but this method is the only right one. The only other solution would be to remove Unbound completely and replace it with something else (please don't, it works very well when used correctly).</p>
<p>Functions like this:<br />$unbound_entries .= "local-data: \"{$host['fqdn']} {$type} {$host['ipaddr']}\"\n";</p>
<p>Should be changed to something like this:<br />$unbound_cmd .= "unbound-control local_data {$host['fqdn']} {$type} {$host['ipaddr']}";</p>
<p>And NEVER EVER bounce the Unbound service. Ever. It is completely unnecessary.</p>
<p>Initial service start / user initiated service restart should probably use the same unbound-control calls for managing all local DNS entries, to prevent both modifying Unbound config files and calling unbound-control to do the same exact thing. Plus it's cleaner, now we don't have 2 code paths to maintain (config files & unbound-control), and we don't use more RAM to store unneeded config file entries.</p>
<p>Additional implementation considerations can be found in the cited post above.</p>