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 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 - 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 - Bug #15084 (New): Upgrading an EFI system installed to ZFS mirror does not upgrade EFI ...https://redmine.pfsense.org/issues/150842023-12-11T16:56:18ZJim Pingle
<p>When an EFI system installed to a ZFS mirror is upgraded, the EFI loader is only updated on the first disk of the mirror (<code>/dev/gpt/efiboot0</code>).</p>
<p>If the system has EFI filesystems on the additional disks, they are not touched during upgrade.</p>
<p>Can be worked around by manually mounting the additional EFI partitions and copying the files.</p>
<p>For example, to update the loader on the second disk:</p>
<pre><code class="shell syntaxhl"><span class="c"># mount -t msdosfs /dev/gpt/efiboot1 /mnt/</span>
<span class="c"># cp -R /boot/efi/ /mnt</span>
<span class="c"># umount /mnt</span>
</code></pre>
<p>Note that systems may or may not actually have a proper EFI filesystem on the additional disks. See <a class="issue tracker-1 status-1 priority-5 priority-high4" title="Bug: Installing to ZFS mirror does not format or populate EFI partition on additional disks (New)" href="https://redmine.pfsense.org/issues/15083">#15083</a></p>
<p>Marked as Plus 24.03/CE 2.8.0 but if it can be fixed in the pfSense-boot package the fix could be picked back to 23.09.1/2.7.2.</p> pfSense - Bug #15082 (New): Upgrade fails due to unmounted EFI filesystemhttps://redmine.pfsense.org/issues/150822023-12-11T14:10:15ZJim Pingle
<p>This may be related to <a class="issue tracker-1 status-1 priority-4 priority-default" title="Bug: Upgrade fails due to undersized EFI filesystem (New)" href="https://redmine.pfsense.org/issues/15081">#15081</a> but it's not definite.</p>
<p>Some upgrades have failed in pfSense-boot if the EFI partition is not manually mounted first.</p>
<p>There are several reports of this where simply manually mounting the EFI partition before starting the upgrade allows it to complete. See <a class="external" href="https://www.reddit.com/r/PFSENSE/comments/18d887u/netgate_releases_pfsense_plus_software_version/kcjcktm/">https://www.reddit.com/r/PFSENSE/comments/18d887u/netgate_releases_pfsense_plus_software_version/kcjcktm/</a> for example.</p>
<p>Marked as Plus 24.03/CE 2.8.0 but if it can be fixed in the pfSense-boot package the fix could be picked back to 23.09.1/2.7.2.</p> pfSense - Bug #15081 (New): Upgrade fails due to undersized EFI filesystemhttps://redmine.pfsense.org/issues/150812023-12-11T14:01:54ZJim Pingle
<p>Some installations as recent as Plus 22.01 / CE 2.6.0 have EFI partitions that were created and/or populated by the old EFIFAT image method. This means that while the EFI <em>partition</em> is 200M, the EFI <em>filesystem</em> is only around 700KB. As a result, these installations are unable to upgrade to recent versions successfully as the loader cannot be updated.</p>
<p>This can be worked around by reformatting the EFI partition directly and copying the appropriate files back into place, as described in this forum post: <a class="external" href="https://forum.netgate.com/post/1140955">https://forum.netgate.com/post/1140955</a></p>
<pre><code class="shell syntaxhl"><span class="c"># mkdir -p /boot/efi</span>
<span class="c"># mount_msdosfs /dev/msdosfs/EFISYS /boot/efi</span>
<span class="c"># mkdir -p /tmp/efitmp</span>
<span class="c"># cp -Rp /boot/efi/* /tmp/efitmp</span>
<span class="c"># umount /boot/efi</span>
<span class="c"># newfs_msdos -F 32 -c 1 -L EFISYS /dev/msdosfs/EFISYS</span>
<span class="c"># mount_msdosfs /dev/msdosfs/EFISYS /boot/efi</span>
<span class="c"># cp -Rp /tmp/efitmp/* /boot/efi/</span>
</code></pre>
<p>There are some potential complications there. For example, the EFI filesystem may not be labeled that way, it could be <code>/dev/gpt/EFISYS</code> or it may have no label at all.</p>
<p>Marked as Plus 24.03/CE 2.8.0 but if it can be fixed in the pfSense-boot package the fix could be picked back to 23.09.1/2.7.2.</p> pfSense - Bug #15032 (Feedback): Kea DHCP sends wrong bootloader file for uefi boothttps://redmine.pfsense.org/issues/150322023-11-25T15:14:36ZDavid Masshardtdavid@masshardt.ch
<p>I already posted this problem in the pfSense forum and was asked to report this issue here. Here is the link of the discussion thread:<br /><a class="external" href="https://forum.netgate.com/topic/184301/kea-dhcp-uefi-pxe-boot-sends-wrong-boot-file">https://forum.netgate.com/topic/184301/kea-dhcp-uefi-pxe-boot-sends-wrong-boot-file</a></p>
<p>I'm using netboot.xyz for network booting and I just switched to Kea DHCP. After the migration I noticed that network booting from UEFI bios does not work anymore, but legacy bios boot still does work.</p>
<p>Here are the configuration values I set in pfSense:</p>
<p>TFTP Server: IP of my netboot server<br />Next Server: IP of my netboot server<br />Default BIOS File Name: netboot.xyz.kpxe<br />UEFI 32 bit File Name: netboot.xyz.efi<br />UEFI 64 bit File Name: netboot.xyz.efi<br />ARM 64 bit File Name: netboot.xyz-arm64.efi</p>
<p>The Kea DHCP server always offers the default netboot.xyz.kpxe file to UEFI machines.</p>
<p>Here are the logs from Kea DHCP for an UEFI bios:</p>
<pre>
Nov 23 12:23:55 kea-dhcp4 14098 INFO [kea-dhcp4.dhcp4.0x3e2f2f5b9300] EVAL_RESULT Expression ipxe_64_lan_pool_0 evaluated to 1
Nov 23 12:23:55 kea-dhcp4 14098 INFO [kea-dhcp4.dhcp4.0x3e2f2f5b9300] EVAL_RESULT Expression ipxe_legacy_lan_pool_0 evaluated to 1
Nov 23 12:23:55 kea-dhcp4 14098 INFO [kea-dhcp4.dhcp4.0x3e2f2f5b9300] EVAL_RESULT Expression ipxe_64_lan evaluated to 1
Nov 23 12:23:55 kea-dhcp4 14098 INFO [kea-dhcp4.dhcp4.0x3e2f2f5b9300] EVAL_RESULT Expression ipxe_legacy_lan evaluated to 1
Nov 23 12:23:55 kea-dhcp4 14098 INFO [kea-dhcp4.leases.0x3e2f2f5b9300] DHCP4_LEASE_ALLOC [hwtype=1 46:15:16:cd:59:84], cid=[no info], tid=0xaccc68dd: lease 172.17.128.2 has been allocated for 86400 seconds
Nov 23 12:23:55 kea-dhcp4 14098 INFO [kea-dhcp4.dhcpsrv.0x3e2f2f5b9300] EVAL_RESULT Expression pool_opt1_0 evaluated to 1
Nov 23 12:23:55 kea-dhcp4 14098 INFO [kea-dhcp4.dhcpsrv.0x3e2f2f5b9300] EVAL_RESULT Expression pool_lan_0 evaluated to 1
</pre>
<p>And here is the generated kea-dhcp4.conf file. (I just removed the reservations)</p>
<pre>
{
"Dhcp4": {
"interfaces-config": {
"interfaces": [
"mlxen0",
"mlxen0.2"
]
},
"lease-database": {
"type": "memfile",
"persist": true,
"name": "/var/lib/kea/dhcp4.leases"
},
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "syslog"
}
],
"severity": "INFO"
}
],
"valid-lifetime": 7200,
"max-valid-lifetime": 86400,
"ip-reservations-unique": false,
"echo-client-id": false,
"option-data": [
{
"name": "domain-name",
"data": "mydomain"
}
],
"option-def": [
{
"space": "dhcp4",
"name": "ldap-server",
"code": 95,
"type": "string"
}
],
"hooks-libraries": [
{
"library": "/usr/local/lib/kea/hooks/libdhcp_lease_cmds.so"
}
],
"control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/kea4-ctrl-socket"
},
"authoritative": true,
"client-classes": [
{
"name": "ipxe_32_lan_pool_0",
"test": "option[93].hex == 0x0006",
"only-if-required": true,
"option-data": [
{
"name": "boot-file-name",
"data": "netboot.xyz.efi"
}
]
},
{
"name": "ipxe_64_lan_pool_0",
"test": "option[93].hex == 0x0007 or option[93].hex == 0x0009",
"only-if-required": true,
"option-data": [
{
"name": "boot-file-name",
"data": "netboot.xyz.efi"
}
]
},
{
"name": "ipxe_64arm_lan_pool_0",
"test": "option[93].hex == 0x000b",
"only-if-required": true,
"option-data": [
{
"name": "boot-file-name",
"data": "netboot.xyz-arm64.efi"
}
]
},
{
"name": "ipxe_legacy_lan_pool_0",
"test": "not member('ipxe_32_lan_pool_0') and not member('ipxe_64_lan_pool_0') and not member('ipxe_64arm_lan_pool_0')",
"only-if-required": true,
"option-data": [
{
"name": "boot-file-name",
"data": "netboot.xyz.kpxe"
}
]
},
{
"name": "pool_lan_0",
"test": "member('ALL')"
},
{
"name": "ipxe_32_lan",
"test": "option[93].hex == 0x0006",
"only-if-required": true,
"option-data": [
{
"name": "boot-file-name",
"data": "netboot.xyz.efi"
}
]
},
{
"name": "ipxe_64_lan",
"test": "option[93].hex == 0x0007 or option[93].hex == 0x0009",
"only-if-required": true,
"option-data": [
{
"name": "boot-file-name",
"data": "netboot.xyz.efi"
}
]
},
{
"name": "ipxe_64arm_lan",
"test": "option[93].hex == 0x000b",
"only-if-required": true,
"option-data": [
{
"name": "boot-file-name",
"data": "netboot.xyz-arm64.efi"
}
]
},
{
"name": "ipxe_legacy_lan",
"test": "not member('ipxe_32_lan') and not member('ipxe_64_lan') and not member('ipxe_64arm_lan')",
"only-if-required": true,
"option-data": [
{
"name": "boot-file-name",
"data": "netboot.xyz.kpxe"
}
]
},
{
"name": "pool_opt1_0",
"test": "member('ALL')"
}
],
"subnet4": [
{
"id": 1,
"subnet": "172.17.0.0/16",
"option-data": [
{
"name": "domain-name",
"data": "mydomain"
},
{
"name": "domain-search",
"data": "mydomain"
},
{
"name": "domain-name-servers",
"data": "172.17.1.1"
},
{
"name": "routers",
"data": "172.17.1.1"
},
{
"name": "netbios-name-servers",
"data": "172.17.2.1"
},
{
"name": "netbios-node-type",
"data": "8"
}
],
"pools": [
{
"pool": "172.17.128.0 - 172.17.128.199",
"client-class": "pool_lan_0",
"option-data": [
{
"name": "domain-name-servers",
"data": "172.17.1.1"
},
{
"name": "tftp-server-name",
"data": "172.17.2.17"
}
],
"require-client-classes": [
"ipxe_legacy_lan_pool_0",
"ipxe_32_lan_pool_0",
"ipxe_64_lan_pool_0",
"ipxe_64arm_lan_pool_0"
]
}
],
"valid-lifetime": 86400,
"next-server": "172.17.2.17",
"require-client-classes": [
"ipxe_legacy_lan",
"ipxe_32_lan",
"ipxe_64_lan",
"ipxe_64arm_lan"
],
"reservations-in-subnet": true
},
{
"id": 2,
"subnet": "172.20.0.0/16",
"option-data": [
{
"name": "domain-name-servers",
"data": "172.20.1.1"
},
{
"name": "routers",
"data": "172.20.1.1"
}
],
"pools": [
{
"pool": "172.20.128.0 - 172.20.128.255",
"client-class": "pool_opt1_0",
"option-data": [
{
"name": "domain-name-servers",
"data": "172.20.1.1"
}
]
}
],
"valid-lifetime": 86400,
"reservations-in-subnet": true
}
]
}
</pre>
<p>I noticed that the legacy classes in the require-client-classes are on top of all the other classes. After i changed the order so that the legacy classes are at the bottom netboot worked for legacy and UEFI boot.</p>
<p>I also created a patch file that fixes the problem in the services.inc file:</p>
<pre><code class="diff syntaxhl"><span class="gd">--- /etc/inc/services.inc.save 2023-11-24 15:19:26.797541000 +0100
</span><span class="gi">+++ /etc/inc/services.inc 2023-11-24 15:24:17.000000000 +0100
</span><span class="p">@@ -1548,7 +1548,7 @@</span>
if (!is_array($keapool['require-client-classes'])) {
$keapool['require-client-classes'] = [];
}
<span class="gd">- array_unshift($keapool['require-client-classes'], $name);
</span><span class="gi">+ $keapool['require-client-classes'][] = $name;
</span> }
if (!empty($poolconf['rootpath'])) {
<span class="p">@@ -1719,7 +1719,7 @@</span>
if (!is_array($keasubnet['require-client-classes'])) {
$keasubnet['require-client-classes'] = [];
}
<span class="gd">- array_unshift($keasubnet['require-client-classes'], $name);
</span><span class="gi">+ $keasubnet['require-client-classes'][] = $name;
</span> }
if (!empty($dhcpifconf['rootpath'])) {
</code></pre>
<p>Can you please take a look at this if this is the correct solution to this problem?</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 - 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 - Todo #10199 (New): Improve Spanish translation interfacehttps://redmine.pfsense.org/issues/101992020-01-22T09:20:34ZAluisco Miguel Ricardo MastrapapfSense - 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>