pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162023-12-15T20:06:02ZpfSense bugtracker
Redmine pfSense - Bug #15098 (New): Wireguard crashes on boot if PPPoE is the default gatewayhttps://redmine.pfsense.org/issues/150982023-12-15T20:06:02ZOskar Stroka
<p>This only seems to happen after a fresh boot, and only if any PPPoE connection is the default gateway. <br />Even the service watchdog can't bring wireguard back up. <br />The workaround is to go to "Status" - "Interfaces", disconnect the PPPoE line and enable it again. <br />After that wireguard will start without a problem.<br />I've only noticed this issue after moving to newer / better hardware.</p> pfSense Packages - Feature #14863 (New): WireGuard suppport for aliaseshttps://redmine.pfsense.org/issues/148632023-10-11T07:53:52ZBob Dig
<p>Allow to use aliases in "Allowed IPs" in the WireGuard Peer config. That would match with the general ability to use aliases for static routes in pfSense, see <a class="external" href="https://forum.netgate.com/topic/183339/feature-request-support-for-aliases">https://forum.netgate.com/topic/183339/feature-request-support-for-aliases</a>.</p> pfSense - Bug #14604 (New): Bugs in dhclient implementation according to RFC 2131https://redmine.pfsense.org/issues/146042023-07-23T14:11:19ZNazar Mokrynskyi
<p>I had issues with one of the ISPs on pfSense and after talking to their tech support and observing what is happening I believe there are bugs in dhclient used by pfSense.<br />It is likely an upstream issue, but I don't use FreeBSD, so I report it here.<br />This is what triggers <a class="external" href="https://redmine.pfsense.org/issues/14237">https://redmine.pfsense.org/issues/14237</a> (which I believe is a buggy gateway groups implementation in pfSense and is a distinct issue, this one is just one way to trigger it, but maybe not the only one).</p>
<p>Dump of communication between pfSense and DHCP server of ISP is also attached.<br />The issue happened on 2.6.x and still happens on 2.7.0 that I'm currently running.</p>
<p>Below is basically an English translation of the response from IPS support representative.</p>
<p>The first thing that is believed to be handling DHCPDISCOVER. According to RFC 2131:<br /> The client begins in INIT state and forms a DHCPDISCOVER message.<br /> The client SHOULD wait a random time between one and ten seconds to<br /> desynchronize the use of DHCP at startup.</p>
<p>So client must wait for DHCPOFFER up to 10 seconds. During this time client can receive answers from multiple DHCP servers and pick settings it prefers.</p>
<p>The other issue is that according to RFC 2131 Unicast request Request Renew must be done between T1 and T2. Time approximately equal tothe lease time<br />(with slight random offset) - T1 timer. pfSense's dhclient only uses T2 (0.85*lease time), this is not quite correct, request according to T2 timer is usually<br />done in case first request to extend lease failed (depends on implementation and DHCP client settings). According to RFC after T2 time client must switch to<br />REBINDING and make boardcast request, which is what happened. If cient doesn't send request/doesn't receive response within lease time then settings must be<br />cleared and procedure of obtaining IP address start over.<br />Current lease time is 10 minutes (600 seconds).<br />Separately sometimes dhclient doesn't send DHCPREQUEST within lease time, for instance record <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Todo: PPTP users integration with user manager (Closed)" href="https://redmine.pfsense.org/issues/34">#34</a> and 37, between then there was more than 600 seconds and<br />procedure to get IP address started over, which is when Internet access was temporarily lost.</p> pfSense - Bug #14397 (New): DHCPv4 client (dhclient) does not use 802.1p Priority tagging on DHCP...https://redmine.pfsense.org/issues/143972023-05-19T14:52:52ZTue Madsen
<p>Some ISPs using VLANs for service, require DHCPv4/v6 Frames to be 802.1p priority tagged. <br />pfSense has the option to do this by either:<br />- Setting VLAN priority tagging in the Interface DHCP options (if you are not using Advanced configuration or a predefined configuration file)<br />- If using advanced configuration: By adding “vlan-pcp x” in the advanced modifier options.</p>
<p>BUG:<br />This priority setting in only used in DISCOVER and RELEASE frames sent by dhclient - NOT in RENEW or REBIND.</p>
<p>This is now causing major problems in France where Orange (Major ISP) has upgraded to also requiring the RENEW frames to be properly VLAN Priority tagged.<br />This causes the uplink to stop working when a renew is due. (About once a day)</p>
<p>I don’t know if the issue is the same in DHCPv6</p>
<p>The issue was patched in OPNsense about a month ago, and they decided to drop the advanced options overwrite of the VLAN priority setting in interface DHCP options. <br />Instead they let the user choose if VLAN priority should be used via the interface DHCP VLAN Priority setting already available. <br />If selected it would - apart from adding “vlan-pcp x” to the dhclient config - also set the priority tag in the builtin pffilter rule that passes Interface DHCP client traffic. This adds the tag to RENEW and REBIND frames.</p>
<p>The issue occurs because dhclient uses a bfg interface for DISCOVER and RELEASE - thus respecting the vlan-pcp settings. But for RENEW it uses a simple socket, and that causes it not to be tagged correctly. In pfSense you cannot create a floating match rule to manually tag the traffic that has higher priority than the builtin pass quick rule for the interface DHCP client.</p> pfSense Packages - Bug #13405 (New): Wireguard: The webgui becomes excessively slow to respond wi...https://redmine.pfsense.org/issues/134052022-08-11T09:12:04ZSteve Wheeler
<p>Webgui pages that include data from Wireguard can become very slow to respond with a large number of elements present (peers/tunnels).</p>
<p>Code that parses the output of 'wg show all dump' creates a delay.</p>
<p>For example we see delays of ~10s opening the Wireguard status page with 80 peers defined on a 6100.</p>
<p>This affects the peers, tunnels and status pages. And to a lesser extent the dashboard when the Wireguard widget is disaplayed.</p> 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 #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 - 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>