pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162024-02-21T19:59:52ZpfSense bugtracker
Redmine pfSense Plus - Feature #15280 (New): Boot Environments 2.0https://redmine.pfsense.org/issues/152802024-02-21T19:59:52ZChristian McDonaldcmcdonald@netgate.com
<p>Changes:</p>
<ul>
<li>Configuration History is now a separate page and is no longer part of Backup & Restore.</li>
<li>Configuration History is now aware of Boot Environments. Supports downloading, deleting and restoring across boot environment boundaries.</li>
<li>System updates are now installed in an offline clone of the running system and booted "temporarily" to facilitate automatic fallback to previous working environment.</li>
<li>Boot Verification is performed when booting temporary Boot Environments. System will automatically reboot into prior boot environment upon boot failure.</li>
</ul>
<p><img src="https://redmine.pfsense.org/attachments/download/5936/clipboard-202402211456-bdjnl.png" alt="" /><br /><img src="https://redmine.pfsense.org/attachments/download/5937/clipboard-202402211457-fegcy.png" alt="" /><br /><img src="https://redmine.pfsense.org/attachments/download/5938/clipboard-202402211457-rbjkq.png" alt="" /><br /><img src="https://redmine.pfsense.org/attachments/download/5939/clipboard-202402211457-fcvqv.png" alt="" /><br /><img src="https://redmine.pfsense.org/attachments/download/5940/clipboard-202402211458-ydyne.png" alt="" /></p> pfSense Packages - Feature #15249 (In Progress): Ability to adjust MTU & MSS on tailscale interfacehttps://redmine.pfsense.org/issues/152492024-02-09T15:48:44ZChristopher Cope
<p>Tailscale itself has an environment variable to adjust this TS_DEBUG_MTU. However, it does seem to be primarily for testing.</p>
<p>We have had a customer reach out to us requesting this.</p>
<p><a class="external" href="https://github.com/tailscale/tailscale/issues/8219">https://github.com/tailscale/tailscale/issues/8219</a></p>
<p>As mentioned on <a class="external" href="https://redmine.pfsense.org/issues/14780">https://redmine.pfsense.org/issues/14780</a> assigning tailscale0 to adjust this value isn't an option.</p> pfSense Packages - Feature #15177 (New): Add an option to choose an interface that the Tailscale ...https://redmine.pfsense.org/issues/151772024-01-20T15:30:19ZDanilo Zrenjanin
<p>Currently, it is not possible to specify the interface that the Tailscale service will use to connect to the Login Server. In a situation where there are multiple WANs, and you want to make changes on the primary WAN, doing so will disconnect you from the VPN.</p> pfSense Packages - Bug #15100 (New): Tailscale IPv6 Exit Node uses first LAN interface when WAN i...https://redmine.pfsense.org/issues/151002023-12-17T03:04:21ZKris Phillips
<p>When Tailscale on pfSense Plus is being used as an exit node for IPv6 connectivity and the WAN interface is set to "Only request an IPv6 prefix, do not request an IPv6 address", it will use the first sequential LAN interface's IPv6 address for outbound connectivity instead. We should probably add an option to Tailscale to select which interface for WAN connectivity is used for the NAT address for IPv4 and IPv6 for outbound connectivity, because this resulted in my internal, secure work VLAN address being used when I had routing policies in Tailscale to only allow access to my home VLAN instead (due to the fact that the work VLAN was the first sequential LAN). Not being able to choose the interface that is used for NAT on the exit node could lead to certain situations where access to resources that shouldn't be is possible under certain circumstances.</p> pfSense - Regression #14930 (Feedback): Clean installation using Auto (ZFS) + MBR (BIOS) does not...https://redmine.pfsense.org/issues/149302023-10-28T02:19:25ZBoycee .
<p>Installing pfSense 2.7.0 using the Auto (ZFS) + MBR (BIOS) options appears successful, however when the installer reboots the system, the system fails to boot successfully, with a message displayed indicating the operating system is missing.</p>
<p>It is possible to install 2.6.0 with these options (Auto (ZFS) + MBR (BIOS)) and successfully upgrade to 2.7.0.</p>
<p>I believe this issue is inherited from FreeBSD:</p>
<p><a class="external" href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267843">https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267843</a><br /><a class="external" href="https://reviews.freebsd.org/D40816">https://reviews.freebsd.org/D40816</a></p>
<p>Whilst this issue should ideally be resolved in future releases of pfSense, I assume it must be considering for future in-place upgrades to avoid “bricking” devices already configured in this way.</p> pfSense - Regression #14410 (New): Behavior of ``earlyshellcmd`` changed, ``ngeth`` interfaces ca...https://redmine.pfsense.org/issues/144102023-05-24T01:27:46ZTaylor Jasko
<p>In pfSense Plus 23.01, I was leveraging <a href="https://docs.netgate.com/pfsense/en/latest/development/boot-commands.html#earlyshellcmd-option" class="external">earlyshellcmd</a> to create a virtual network interface & handle 802.1x authentication <em>before</em> pfSense checks whether reassignment of interfaces is required. While this specific use case has been <a href="https://docs.netgate.com/pfsense/en/latest/recipes/authbridge.html" class="external">recently solved</a> in 23.05 through other officially supported ways, there's another issue at hand here.</p>
<p>For some background, I'm utilizing <code>pfatt</code> (as called out in the link above) to handle 802.1x auth with AT&T. After applying the update, pfSense was unable to boot due to not finding the <code>ngeth0</code> interface that the <code>pfatt</code> script was tasked to create. This is because in 23.05, I have confirmed that the configured shell commands with the <code>earlyshellcmd</code> option are being executed later in the boot sequence than the previous release. More specifically, the <code>/etc/rc.bootup</code> PHP script was updated so that the early shell commands (which are called off by <code>system_do_shell_commands(1)</code>) are executed after the <code>while (is_interface_mismatch() == true)...</code> code block (which then halts the boot process if it fails). Previously to 23.05, <code>system_do_shell_commands(1)</code> was called before that aforementioned <code>while</code> loop, just like how pfSense CE functions today, which can be seen in the code <a href="https://github.com/pfsense/pfsense/blob/9fab01eae0698ce23979663fc18d58536dc305f0/src/etc/rc.bootup#L121-L167" class="external">here</a>.</p>
<p>While my particular issue can be solved by the newly introduced auth bridging functionality, it still begs the question of whether the changed execution sequence of <code>earlyshellcmd</code> commands being impacted was intentional or not; from my standpoint, it's a regression as other pfSense Plus users may be relying on these early shell commands executing before the networking interfaces are checked.</p>
<p>Specifically to my use case, I'll switch over to the new way of configuring this authentication method soon, however, I wanted to file this issue so the pfSense Plus team is aware of this regression. Please let me know if you require any more insight into this problem.</p>
<p>Thanks!</p> pfSense Plus - Feature #14297 (New): Add Option for Vendor Class ID in DHCP Clienthttps://redmine.pfsense.org/issues/142972023-04-21T15:07:26ZKris Phillips
<p>Some ISPs require a Vendor Class ID be sent (option 60) when requesting DHCP. This can currently be accomplished in pfSense with vendor-class-identifier manually added to a dhcp config file, but adding this as a field would be helpful.</p> pfSense - Feature #13422 (New): Add a 'type' field to the DHCPv6 server Additional BOOTP/DHCP Opt...https://redmine.pfsense.org/issues/134222022-08-17T09:32:08ZSteve Wheeler
<p>In the IPv4 DHCP server the Additional BOOTP/DHCP Options allow setting the option type. Currently the DHCPv6 server can only create options of type 'text'.<br />All options added there appear in the dhcpv6.conf file as:<br /><pre>
option custom-opt1-0 code 69 = text;
...
option custom-opt1-0 "test";
</pre></p>
<p>Add the type field to the DHCPv6 server as it is for the IPv4 server to allow other types to be added.</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 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 - 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>