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 - 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 - 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 Packages - Feature #13474 (New): Don't set ListenPort in wireguardhttps://redmine.pfsense.org/issues/134742022-09-06T19:08:51ZFlole Systems
<p>Currently it is not possible to not set the ListenPort setting for wireguard. I suggest to use the special value 0 as a port and then mentioning that setting it to 0 disables this.</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 - 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 - Todo #10199 (New): Improve Spanish translation interfacehttps://redmine.pfsense.org/issues/101992020-01-22T09:20:34ZAluisco Miguel Ricardo Mastrapa