pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162024-03-10T23:09:39ZpfSense bugtracker
Redmine pfSense - Bug #15328 (New): Kea DHCP corrupts existing leases when a new DHCP pool is addedhttps://redmine.pfsense.org/issues/153282024-03-10T23:09:39ZTom Lane
<p>I set up a couple of DHCP pools for VLANs on a new Netgate 4200 (running pfsense+ 23.09.1), which is replacing an EdgeRouter-X that had been serving DHCP to the same clients. That went fine, and I watched several of the existing VLAN clients re-acquire their existing addresses from the new server. Then I added another DHCP pool attached directly to the PORT2LAN interface. That completely confused matters for existing leases: the server actively rejected attempts to renew those leases and gave out addresses of its own choosing. Now I am seeing two different entries in the DHCP Leases status page for the same MAC address, which surely should not happen. Digging in the DHCP log entries, it looks like when the server was restarted because of the pool addition, all the lease reloads failed with complaints like</p>
<p><code>Mar 10 16:09:18 kea-dhcp4 39285 WARN [kea-dhcp4.dhcpsrv.0x401b3c12000] DHCPSRV_LEASE_SANITY_FAIL The lease 10.0.20.41 with subnet-id 2 failed subnet-id checks (the lease should have subnet-id 3).<br /></code><br />10.0.20.41 is still shown (though as "down") in the Leases page, but there's also an entry for that client with its forcibly-assigned new IP address.</p>
<p>This isn't a fatal problem, assuming that the server manages to keep re-issuing these newly-chosen addresses, but it's mildly annoying. I'm not sure if there will be any outright conflicts as the remaining clients try to renew their leases.</p> 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 #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 #15172 (New): Tailscale interface goes down without reasonhttps://redmine.pfsense.org/issues/151722024-01-18T01:47:04ZCarlos Montalvo J.
<p>Tailscale on pfSense 2.7.2-RELEASE (tailscale package v0.1.4 [tailscale-1.54.0])</p>
<p>On a VM (Proxmox v8.x (lastest with OpenVSwitch)) VMXNET interfaces.<br />Service Watchdog should restart the VPN, but it doesn't... (Does not look at the interface status)<br /><img src="https://redmine.pfsense.org/attachments/download/5855/clipboard-202401172043-aqnjt.png" title="Kernel logs" alt="Kernel logs" /><br /><img src="https://redmine.pfsense.org/attachments/download/5857/clipboard-202401172044-hk5yq.png" title="Service watchdog config" alt="Service watchdog config" /></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 Plus - Feature #15022 (New): Package install/reinstall feature request.https://redmine.pfsense.org/issues/150222023-11-22T01:23:31ZJonathan Lee
<p>Hello fellow Redmine community members. I have noticed time and time again I have the ability to scroll during package installs to see the what package dependencies are installing and to check version numbers but I can't get it to stay still for longer than a split second before it auto scrolls back to the bottom. Can we make this stay where users are when the scroll and remove the auto scroll function?</p>
<p>We currently have no way to see the dependency information after it scrolls past because auto scroll takes us back to the bottom again.</p>
<p>See attached photo, I wanted to check what dependency versions were installed, Everytime you scroll it defaults to bottom again.</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 #14556 (New): Tailscale dropping routes from FIBhttps://redmine.pfsense.org/issues/145562023-07-07T14:28:17ZChris Linstruth
<p>Installation has several tailscale nodes. The problematic node is a 6100. Some of the other nodes are 2100s.</p>
<p>At some point in the past, it started malfunctioning on one of the nodes whenever specific types of changes are made.</p>
<ul>
<li>Add or remove a node with routed subnets, all routes drop. Can successfully add/remove nodes without routes. This is on the tailscale machine config.</li>
<li>Simply marking a route as active or inactive (tailscale edit route settings) will also trigger it.</li>
</ul>
<p>It occurs occasionally without any changes being made.<br />Bounce the tailscale process on that 6100 node and they return.<br />The routes just drop from the kernel FIB.<br />Only on the one node.</p>
<p>There is essentially nothing logged (DEBUG logging level) regarding the actions of the tailscale routing protocol. Nor is there anything of troubleshooting value on the tailscale cloud site.</p>
<p>All IPv4 tailscale routes drop including host routes. It is probably noteworthy that the IPv6 /48 is still in the table and tailscaled is still running.</p>
<p>Another possibly interesting note is the routes advertised by the 6100 that drops the routes remain advertised into the tailnet and present on the other nodes.</p>
<p>The nodes are still showing as “idle” so tailscale is still “up.”</p>
<p>Attempted to duplicate this by adding a tailnet to 4 pfSense nodes with routes and two devices without routes. It could not be made to misbehave.</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 - 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 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 Plus - Feature #13740 (New): Feature Request: Mark Boot Environments with different prope...https://redmine.pfsense.org/issues/137402022-12-09T14:04:10ZJonas R
<p>Boot snapshots are awesome. However. I see huge potential for expanding the features on these. So here are a few suggestions</p>
<p>Mark a snapshot as forbidden to boot.<br />This comes from a weird situaton from my 6100. Where the first boot would work just perfectly. However, ever subsequent boot would result in a completely broken LAN. So I had to be suuuper careful not to boot the last remaining snapshot of my "working" system whilst trouble shooting. But if I had been able to mark it so it wasn't allowed to be booted. Then this would've been real handy.</p>
<p>Mark snapshot with Deletion Prevention:<br />This is basically an option to mark a specific snapshot so that it isn't allowed to be deleted, whilst the "Prevent from being deleted"-flag is set. Or something similar. Suggestion is to have it as a check box from within the edit-page. This could then disable the Trash-icon on the main paige.</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 - 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 - Todo #10199 (New): Improve Spanish translation interfacehttps://redmine.pfsense.org/issues/101992020-01-22T09:20:34ZAluisco Miguel Ricardo Mastrapa