pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162024-02-21T20:49:15ZpfSense bugtracker
Redmine pfSense Packages - Todo #15281 (Confirmed): Upgrade Tailscale to 1.6.0https://redmine.pfsense.org/issues/152812024-02-21T20:49:15ZChris W
<p>Plus 24.03 has tailscale-1.56.1 available in the Package Manager. Would be great to pull in 1.6.0 if possible.</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 - 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 - 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 Packages - Bug #14748 (Feedback): FRR reload script is not executed properlyhttps://redmine.pfsense.org/issues/147482023-09-05T19:39:31Zyon Liuinfo@ipv6china.com
<p>I deleted frr Neighbors through webgui, but it was not deleted in frr.</p>
<p>That is, the deletion operation through pf webgui is not reflected in the frr routing system</p>
<p>test with <br />23.09-DEVELOPMENT (amd64)<br />built on Tue Sep 05 05:55:55 UTC 2023<br />FreeBSD 14.0-ALPHA2</p> pfSense Packages - Bug #14676 (Confirmed): Listening Port option in the Tailscale configurator is...https://redmine.pfsense.org/issues/146762023-08-10T02:54:52ZDavid G
<p>The tailscaled process starts and listens on a random port, instead of the one specified. This causes things like direct tunnels between tailscale node to not work (WAN rule), thus causing all traffic to be relayed when the other device is behind double NAT or other hard NAT types. If I go and see what port is actually being used and adjust me WAN rule, suddenly direct connections are all established.</p>
<p>How to reproduce:<br />1. Set a listening port<br />2. Start the tailscale service<br />3. View what the actual port is being listened on by executing "sockstat -l"</p> pfSense - Feature #14620 (Assigned): Support running DHCPv4 Server and DHCPv4 Relay at the same t...https://redmine.pfsense.org/issues/146202023-07-27T20:27:59ZChristian McDonaldcmcdonald@netgate.compfSense Packages - Bug #14491 (Confirmed): FRR not starting with AgentX enabledhttps://redmine.pfsense.org/issues/144912023-06-20T18:43:05Zbeermount beermount
<p>After upgrading to pfSense 2.7.0 Beta, FRR wont't start with AgentX enabled in the configuration.</p>
<p>Syslog<br /><pre>
Jun 18 16:49:49 root 85099 /usr/local/etc/rc.d/frr: WARNING: failed to start ospfd
Jun 18 16:49:49 root 79090 /usr/local/etc/rc.d/frr: WARNING: failed to start zebra
</pre></p>
<p>Output from interactively trying to start frr.</p>
<pre>
/usr/local/etc/rc.d/frr.sh start
Performing intergrated config test
Starting FRR Checking intergrated config...
Checking vtysh.conf OK
Starting zebra.
loading module "snmp" failed: Shared object "snmp" not found, required by "zebra" /usr/local/etc/rc.d/frr: WARNING: failed to start zebra
Starting staticd.
Starting ospfd.
loading module "snmp" failed: Shared object "snmp" not found, required by "ospfd" /usr/local/etc/rc.d/frr: WARNING: failed to start ospfd
Booting for integrated-vtysh-config..
</pre> 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 - Todo #10199 (New): Improve Spanish translation interfacehttps://redmine.pfsense.org/issues/101992020-01-22T09:20:34ZAluisco Miguel Ricardo MastrapapfSense - Bug #6605 (Confirmed): rc.linkup logic issues with actions takenhttps://redmine.pfsense.org/issues/66052016-07-12T19:46:41ZChris Buechlercbuechler@gmail.com
<p>The actions taken by rc.linkup differ depending on whether the interface has a static or no IPv4 and IPv6 IP, and every other case (where either the v4 or v6 type of the interface is dynamic). <br /><a class="external" href="https://github.com/pfsense/pfsense/blob/RELENG_2_3/src/etc/rc.linkup#L70">https://github.com/pfsense/pfsense/blob/RELENG_2_3/src/etc/rc.linkup#L70</a></p>
<p>While there are no doubt some edge case reasons for that being the way it is, it's not sensible logic in general. The actions taken should be much closer to the same between them.</p>
<p>The only known problem this causes is with CARP. The interface_bring_down function removes CARP VIPs from the interface. If you have a static v4 and track6 LAN, this makes CARP get into dual master on WAN when the LAN loses link. What should happen is the CARP IP stays in INIT, which increments net.inet.carp.demotion by 240, which makes the secondary take over for the WAN VIPs. What actually happens is it increments demotion by 240, fails over to the secondary, then the VIP is deleted from the LAN on primary so demotion gets a +240 on the primary because the VIP is gone, and the primary takes back over master. Then you have dual master on WAN.</p>
<p>interface_bring_down should never be run on an interface where a CARP VIP resides to avoid this situation. It's questionable whether it's ever actually necessary or desirable when losing link on a NIC.</p>
<p>This is a potentially touchy area for regressions, so it'll need a good deal of review, testing and time to run in snapshots.</p> 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>