pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162023-09-05T19:39:31ZpfSense bugtracker
Redmine pfSense Packages - Bug #14748 (Feedback): FRR reload script is not executed properlyhttps://redmine.pfsense.org/issues/147482023-09-05T19:39:31Zyon Liuinfo@ipv6china.com
<p>I deleted frr Neighbors through webgui, but it was not deleted in frr.</p>
<p>That is, the deletion operation through pf webgui is not reflected in the frr routing system</p>
<p>test with <br />23.09-DEVELOPMENT (amd64)<br />built on Tue Sep 05 05:55:55 UTC 2023<br />FreeBSD 14.0-ALPHA2</p> pfSense - Bug #14613 (New): Incorrect wireguard control panel status managementhttps://redmine.pfsense.org/issues/146132023-07-26T14:59:29Zhao zhang
<p><img src="https://redmine.pfsense.org/attachments/download/5201/clipboard-202307262256-rlh8k.png" alt="" /><br />Wireguard can still be clicked on to start while in the boot state and is unresponsive when clicked on, making wireguard uncontrollable.<br />pfsense2.7<br />pfSense-pkg-WireGuard 0.2.0_2</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 Packages - Bug #14491 (Confirmed): FRR not starting with AgentX enabledhttps://redmine.pfsense.org/issues/144912023-06-20T18:43:05Zbeermount beermount
<p>After upgrading to pfSense 2.7.0 Beta, FRR wont't start with AgentX enabled in the configuration.</p>
<p>Syslog<br /><pre>
Jun 18 16:49:49 root 85099 /usr/local/etc/rc.d/frr: WARNING: failed to start ospfd
Jun 18 16:49:49 root 79090 /usr/local/etc/rc.d/frr: WARNING: failed to start zebra
</pre></p>
<p>Output from interactively trying to start frr.</p>
<pre>
/usr/local/etc/rc.d/frr.sh start
Performing intergrated config test
Starting FRR Checking intergrated config...
Checking vtysh.conf OK
Starting zebra.
loading module "snmp" failed: Shared object "snmp" not found, required by "zebra" /usr/local/etc/rc.d/frr: WARNING: failed to start zebra
Starting staticd.
Starting ospfd.
loading module "snmp" failed: Shared object "snmp" not found, required by "ospfd" /usr/local/etc/rc.d/frr: WARNING: failed to start ospfd
Booting for integrated-vtysh-config..
</pre> 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 #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 - 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 - 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>