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 - 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 #14983 (New): Upgrade can fail when unexpected EFI partitions are present.https://redmine.pfsense.org/issues/149832023-11-14T15:49:22ZSteve Wheeler
<p>pfSense-upgrade can fail when the pfSense-boot post install script tries to update the bot loader if the first EFI partition is not on the boot drive.</p>
<p>For example if the main boot drive is not installed as UEFI and the installation media is still present. The script tries and fails to update the wrong drive aborting the upgrade:</p>
<pre>
Number of packages to be reinstalled: 1
[1/1] Reinstalling pfSense-boot-23.09...
[1/1] Extracting pfSense-boot-23.09: .......... done
mount_msdosfs: /dev/msdosfs/EFISYS: Read-only file system
pkg-static: POST-INSTALL script failed
failed.
__RC=1 __REBOOT_AFTER=10
</pre> pfSense - Regression #14970 (Feedback): Static ARP assignments lose ``permanent`` flag in ARP tablehttps://redmine.pfsense.org/issues/149702023-11-11T21:01:26ZDenny Page
<p>Arp flips back and forth between reporting static arp entries as permanent or having timeouts with large negative values, and eventually looses the concept that entries are static at all.</p>
<pre>
[23.09-RELEASE][root@fw]/root: arp -s 192.168.230.202 70:b3:d5:e3:d0:40
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in 938 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 938 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in 938 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -s 192.168.230.201 70:b3:d5:e3:d0:22
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in 841 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 841 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 permanent [ethernet]
[23.09-RELEASE][root@fw]/root: arp -s 192.168.230.203 70:b3:d5:e3:d0:23
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 permanent [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 816 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 permanent [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 permanent [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 812 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 permanent [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in -1699735173 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in -1699735173 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 808 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in -1699735173 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 permanent [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 802 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 permanent [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 permanent [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 797 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 permanent [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in -1699735254 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in -1699735254 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 727 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in -1699735254 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in -1699735261 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in -1699735261 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 720 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in -1699735261 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in -1699735265 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in -1699735265 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 716 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in -1699735265 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 permanent [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 690 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 permanent [ethernet]
[23.09-RELEASE][root@fw]/root:
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 permanent [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 660 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 permanent [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in -1699735329 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in -1699735329 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 652 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in -1699735329 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 permanent [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 649 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 permanent [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in -1699735337 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in -1699735337 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 644 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in -1699735337 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 permanent [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 641 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 permanent [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in -1699735343 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in -1699735343 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 638 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in -1699735343 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in -1699735345 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in -1699735345 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 636 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in -1699735345 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 permanent [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 permanent [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 635 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 permanent [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in -1699735351 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in -1699735351 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 630 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in -1699735351 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in -1699735353 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in -1699735353 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 628 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in -1699735353 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in 1140 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in 1140 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 1140 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in 1140 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in 1113 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in 1113 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 1113 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in 1113 seconds [ethernet]
[23.09-RELEASE][root@fw]/root: arp -i ix0 -a | grep leontp
leontp2 (192.168.230.202) at 70:b3:d5:e3:d0:40 on ix0 expires in 1112 seconds [ethernet]
leontp3 (192.168.230.203) at 70:b3:d5:e3:d0:23 on ix0 expires in 1112 seconds [ethernet]
leontp0 (192.168.230.200) at a0:39:75:00:00:7f on ix0 expires in 1112 seconds [ethernet]
leontp1 (192.168.230.201) at 70:b3:d5:e3:d0:22 on ix0 expires in 1112 seconds [ethernet]
[23.09-RELEASE][root@fw]/root:
</pre> 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 - 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 - 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 - 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 - 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> pfSense - 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>