pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162024-03-11T16:52:27ZpfSense bugtracker
Redmine pfSense - Feature #15331 (New): Client (service) for CloudFlare WARP/WAR+https://redmine.pfsense.org/issues/153312024-03-11T16:52:27ZSergei Shablovsky
<p><strong>On now CloudFlare in fact for a couple of years are fastest and reliable proxy and SDN for most users.</strong><br />(Sometimes magistrale and core borders routing problems that hit Akamai, make a not big touch on CF.)<br />Most of “child problems” as newly and fast growing company HAS GONE AWAY.</p>
<p>And <strong>NUMBER OF POINT OF PERSISTENCE (data centers, servers on colocation) ARE CONSTANTLY GROW!</strong></p>
<p><strong>All this make WARP/WARP+ CloudFlare service more and more wanted not only by most of ordinary users, advanced users, but small and middle private business and government organization.</strong></p>
<p>And as a result, from 2022 more and more ciders try to realize CloudFlare WARP/WARP+ client code for various OSs, especially on which routers/firewalls are based.</p>
<p>Please take a look on <br />thread on pfSense CE<br /><a class="external" href="https://forum.netgate.com/topic/177267/connecting-to-cloudflare-surely-its-possible">https://forum.netgate.com/topic/177267/connecting-to-cloudflare-surely-its-possible</a></p>
<p>thread on CloudFlare</p>
<p><a class="external" href="https://community.cloudflare.com/t/warp-client-for-freebsd-based-firewalls-eg-pfsense-opnsense/426717/1">https://community.cloudflare.com/t/warp-client-for-freebsd-based-firewalls-eg-pfsense-opnsense/426717/1</a></p>
<p>So, the downline of all of this:<br />making CloudFlare WARP/WARP+ client as separate package for pfSense is not so much time and efforts.</p>
<p>If DevTeam make it right now, testing and feedbacks from users within summer (when not so much business workload and negative impact would be minimal) for the next upcoming release (2.7.3-REL) this *adding more value to pfSense” and growing distance from concurrent OPNsense.</p> pfSense - Feature #15221 (New): Make System Tunables table sortablehttps://redmine.pfsense.org/issues/152212024-01-31T19:43:54ZRonald Antonyrcfa+pfsense.org@cubiculum.com
<p>On the System > Advanced page's System Tunables tab, it's really hard to <br />a) find/check values, since they are in no particular order<br />b) compare the settings of two machines, because, again, the values are in no particular order.</p>
<p>Being able to sort them by the Tunable Name is particularly important as it seems the Description of these fields has been changed over the years, so two systems originally set up at different times with different versions of pfSense have different descriptions for the same field, making it even harder to find/compare the values.</p> pfSense - Bug #15083 (New): Installing to ZFS mirror does not format or populate EFI partition on...https://redmine.pfsense.org/issues/150832023-12-11T16:28:54ZJim Pingle
<p>Installing Plus 23.09.1 or CE 2.7.2 to a ZFS mirror does not format or populate the EFI partition on the additional disks of the mirror. Only the first disk in the mirror has a populated EFI filesystem with the expected loader files.</p>
<p>The EFI Partition for the second disk (or later) is created and labeled as <code>/dev/gpt/efiboot1</code> (and so on) but there is no filesystem on that partition (and thus, no files).</p>
<p>Should the first disk in the mirror fail, this would leave the system unbootable.</p>
<p>Can be worked around by manually creating and populating the additional EFI partition(s) post-install</p>
<p>For example, to format and populate the EFI filesystem on the second disk of the mirror:</p>
<pre><code class="shell syntaxhl"><span class="c"># newfs_msdos -F 32 -c 1 -L EFISYS1 /dev/gpt/efiboot1</span>
<span class="c"># mount_msdosfs /dev/gpt/efiboot1 /mnt</span>
<span class="c"># cp -R /boot/efi/ /mnt</span>
<span class="c"># umount /mnt</span>
</code></pre> pfSense - Bug #15015 (New): Static routes not workinghttps://redmine.pfsense.org/issues/150152023-11-20T17:53:07ZSilviu Bajenaru
<p>Hello,</p>
<p>This morning I updated to PFSense 2.7.1 from 2.7.0. Now, I just tried to add a dynamic gateway and a static route. Unfortunately, the static route is not being added to the routing table. I restored the VM backup from this morning, before I updated, added the same gateway and static route and it was added to the routing table, and everything works fine.<br />I've set the priority to Urgent since this is quite bad for a router...?</p>
More info about my setup: I've got three sites, let's call them A, B and C. There is an IPSec tunnel between A and B, and one between B and C. Both tunnels are set with Mode VTI. I've assigned the ipsec interfaces and set the gateways and routes:<br />Site A has a gateway set on the IPSec interface and a route for site C that uses that gateway.<br />Site B has two gateways (one for each IPSec tunnel) and the following routes:
<ul>
<li>route to site A via the IPSec interface - gateway - going to site A</li>
<li>route to site B via the IPSec interface - gateway - going to site B<br />Site C has a gateway set on the IPSec interface and a route for site A that uses that gateway.<br />Site A was updated this morning to PFSense 2.7.1, while Site C is running 2.7.0.<br />Site A DOES NOT have the static routes added to the routing table.<br />Site C does have the static routes added to the routing table.</li>
</ul>
<p>Once I reverted Site A to 2.7.0, I did the same config again and the routes were added to the routing table.</p>
<p>Thank you.</p> pfSense - Feature #14923 (New): Feature request - Backup encryption using a public keyhttps://redmine.pfsense.org/issues/149232023-10-26T20:52:53ZWolfgang Thegreat
<p>This feature request is following a community post at <a class="external" href="https://forum.netgate.com/topic/183662/backup-encryption-using-a-public-key">https://forum.netgate.com/topic/183662/backup-encryption-using-a-public-key</a></p>
<p>Hello,</p>
<p>Currently the manual backup encryption is using a password the user needs to submit to the device, which is not so friendly and somewhat less secure, since browsers are multi-purpose and has plugins/addons that at times discovered as malicious.</p>
<p>So, I thought - why not do this encryption using a public key?<br />It can use the current users mechanism, as a user object can store a public key value, currently for SSH access authentication, but it can also be used to encrypt and sign the backup. One can even create a special user just for the goal of backup.</p>
<p>I guess this method can also be applied to the scheduled backups to the pfSense cloud, the "Auto Config Backup" feature.</p>
<p>This way the risk of password leak/exposure or even folks fear that pfSense will "steal" this password, will be gone.<br />Also, it should be easier for users to verify the authenticity and integrity of the output file and to decrypt it offline when needed, to read the plain text configuration XML file.</p>
<p>Thank you!</p> pfSense - Bug #14906 (New): DHCPv4 server self-assigning address to own DHCP client-enabled inter...https://redmine.pfsense.org/issues/149062023-10-22T15:24:26ZLuca Piccirillo
<p>Assume three NICs: igc0, igc1, igc2<br />Assume a single bridge: bridge0 (OPT2, OPT3)<br />And a VLAN: igc0.1036</p>
<p>Interfaces assignment as follows:<br />WAN -> igc0.1036 -> IPv4 (DHCP): 1.2.3.4/30<br />LAN -> bridge0 -> IPv4 (static): 192.168.1.1/24<br />OPT1 -> igc0 -> IPv4 (static): 192.168.100.2/24<br />OPT2 -> igc1<br />OPT3 -> igc2</p>
<p>DHCP & RA enabled for LAN only.</p>
<p>The problem: switching OPT1 IPv4 settings from static to DHCP makes pfSense to assign itself an address from the LAN pool, also creating a wrong on-link route for its LAN subnet over the igc0 port, which is the underlying IF of WAN.</p>
<p>Of course this is easily noticeable when no other DHCP serve is active on that igc0 port broadcast domain.</p> pfSense - Bug #14891 (New): High CPU usage when interface get down and up due to proces check_rel...https://redmine.pfsense.org/issues/148912023-10-18T10:40:27ZThijs K
<p>Today I noticed that the cpu usage was high on my pfSense appliance (N5105, I226). <br />After looking in top I see that check_reload_status is fully taxing one core. <br />This process seems to be triggered when the wan interface comes down and up. <br />The process keeps running and taxing the CPU until it is manually stopped.</p> pfSense - Bug #14741 (New): PHP error in DNS Forwarder host overrides when the language is set to...https://redmine.pfsense.org/issues/147412023-09-02T10:26:29ZNicolas PISTER
<p>A PHP error occur when a user try to add or modify Host Override in DNS Forwarder module</p>
<pre>
amd64
14.0-CURRENT
FreeBSD 14.0-CURRENT #1 RELENG_2_7_0-n255866-686c8d3c1f0: Wed Jun 28 04:21:19 UTC 2023 root@freebsd:/var/jenkins/workspace/pfSense-CE-snapshots-2_7_0-main/obj/amd64/LwYAddCr/var/jenkins/workspace/pfSense-CE-snapshots-2_7_0-main/sources/FreeBSD-src-REL
Crash report details:
PHP Errors:
[02-Sep-2023 11:55:24 Europe/Paris] PHP Fatal error: Uncaught ValueError: Unknown format specifier "p" in /usr/local/www/classes/Form/Input.class.php:127
Stack trace:
#0 /usr/local/www/classes/Form/Input.class.php(127): sprintf('Nom de domaine ...', '<br />')
#1 /usr/local/www/services_dnsmasq_edit.php(85): Form_Input->setHelp('Domain of the h...', '<br />')
#2 {main}
thrown in /usr/local/www/classes/Form/Input.class.php on line 127
[02-Sep-2023 11:58:37 Europe/Paris] PHP Fatal error: Uncaught ValueError: Unknown format specifier "p" in /usr/local/www/classes/Form/Input.class.php:127
Stack trace:
#0 /usr/local/www/classes/Form/Input.class.php(127): sprintf('Nom de domaine ...', '<br />')
#1 /usr/local/www/services_dnsmasq_edit.php(85): Form_Input->setHelp('Domain of the h...', '<br />')
#2 {main}
thrown in /usr/local/www/classes/Form/Input.class.php on line 127
[02-Sep-2023 11:58:46 Europe/Paris] PHP Fatal error: Uncaught ValueError: Unknown format specifier "p" in /usr/local/www/classes/Form/Input.class.php:127
Stack trace:
#0 /usr/local/www/classes/Form/Input.class.php(127): sprintf('Nom de domaine ...', '<br />')
#1 /usr/local/www/services_dnsmasq_edit.php(85): Form_Input->setHelp('Domain of the h...', '<br />')
#2 {main}
thrown in /usr/local/www/classes/Form/Input.class.php on line 127
</pre>
<p>I think it come from a french translation file because when i use original language, everithing works.</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 #14431 (Feedback): Sending IPv6 traffic on a disabled interface can trigger ...https://redmine.pfsense.org/issues/144312023-05-29T14:41:52ZSteve Wheeler
<p>This issue was hidden by <a class="external" href="https://redmine.pfsense.org/issues/14164">https://redmine.pfsense.org/issues/14164</a> but now that is solved in 23.05 is being seen.</p>
<pre>
db:1:pfs> bt
Tracing pid 93402 tid 103857 td 0xfffffe00cf7cac80
kdb_enter() at kdb_enter+0x32/frame 0xfffffe00cf8a0800
vpanic() at vpanic+0x183/frame 0xfffffe00cf8a0850
panic() at panic+0x43/frame 0xfffffe00cf8a08b0
trap_fatal() at trap_fatal+0x409/frame 0xfffffe00cf8a0910
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe00cf8a0970
calltrap() at calltrap+0x8/frame 0xfffffe00cf8a0970
--- trap 0xc, rip = 0xffffffff80f5a036, rsp = 0xfffffe00cf8a0a40, rbp = 0xfffffe00cf8a0a70 ---
in6_selecthlim() at in6_selecthlim+0x96/frame 0xfffffe00cf8a0a70
tcp_default_output() at tcp_default_output+0x1ded/frame 0xfffffe00cf8a0c60
tcp_output() at tcp_output+0x14/frame 0xfffffe00cf8a0c80
tcp6_usr_connect() at tcp6_usr_connect+0x2f4/frame 0xfffffe00cf8a0d10
soconnectat() at soconnectat+0x9e/frame 0xfffffe00cf8a0d60
kern_connectat() at kern_connectat+0xc9/frame 0xfffffe00cf8a0dc0
sys_connect() at sys_connect+0x75/frame 0xfffffe00cf8a0e00
amd64_syscall() at amd64_syscall+0x109/frame 0xfffffe00cf8a0f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00cf8a0f30
--- syscall (98, FreeBSD ELF64, connect), rip = 0x800fddc8a, rsp = 0x7fffdf5f8c98, rbp = 0x7fffdf5f8cd0 ---
</pre>
<pre>
db:1:pfs> bt
Tracing pid 68614 tid 100330 td 0xfffffe00cf325720
kdb_enter() at kdb_enter+0x32/frame 0xfffffe00c7d955f0
vpanic() at vpanic+0x183/frame 0xfffffe00c7d95640
panic() at panic+0x43/frame 0xfffffe00c7d956a0
trap_fatal() at trap_fatal+0x409/frame 0xfffffe00c7d95700
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe00c7d95760
calltrap() at calltrap+0x8/frame 0xfffffe00c7d95760
--- trap 0xc, rip = 0xffffffff80f63aa4, rsp = 0xfffffe00c7d95830, rbp = 0xfffffe00c7d95a50 ---
ip6_output() at ip6_output+0xb74/frame 0xfffffe00c7d95a50
udp6_send() at udp6_send+0x78e/frame 0xfffffe00c7d95c10
sosend_dgram() at sosend_dgram+0x357/frame 0xfffffe00c7d95c70
sousrsend() at sousrsend+0x5f/frame 0xfffffe00c7d95cd0
kern_sendit() at kern_sendit+0x132/frame 0xfffffe00c7d95d60
sendit() at sendit+0xb7/frame 0xfffffe00c7d95db0
sys_sendto() at sys_sendto+0x4d/frame 0xfffffe00c7d95e00
amd64_syscall() at amd64_syscall+0x109/frame 0xfffffe00c7d95f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00c7d95f30
--- syscall (133, FreeBSD ELF64, sendto), rip = 0x823f95f2a, rsp = 0x8202cea88, rbp = 0x8202cead0 ---
</pre>
<pre>
db:1:pfs> bt
Tracing pid 2 tid 100041 td 0xfffffe0085264560
kdb_enter() at kdb_enter+0x32/frame 0xfffffe00850ad910
vpanic() at vpanic+0x183/frame 0xfffffe00850ad960
panic() at panic+0x43/frame 0xfffffe00850ad9c0
trap_fatal() at trap_fatal+0x409/frame 0xfffffe00850ada20
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe00850ada80
calltrap() at calltrap+0x8/frame 0xfffffe00850ada80
--- trap 0xc, rip = 0xffffffff80f5a036, rsp = 0xfffffe00850adb50, rbp = 0xfffffe00850adb80 ---
in6_selecthlim() at in6_selecthlim+0x96/frame 0xfffffe00850adb80
tcp_default_output() at tcp_default_output+0x1ded/frame 0xfffffe00850add70
tcp_timer_rexmt() at tcp_timer_rexmt+0x514/frame 0xfffffe00850addd0
tcp_timer_enter() at tcp_timer_enter+0x102/frame 0xfffffe00850ade10
softclock_call_cc() at softclock_call_cc+0x13c/frame 0xfffffe00850adec0
softclock_thread() at softclock_thread+0xe9/frame 0xfffffe00850adef0
fork_exit() at fork_exit+0x7d/frame 0xfffffe00850adf30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00850adf30
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
db:1:pfs>
</pre> 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 - Bug #9295 (New): IPv6 PD does not work with PPPOE (Server & Client)https://redmine.pfsense.org/issues/92952019-01-29T11:51:01ZDirk Steingäßer
<p>Hi,</p>
<p>as encountering DHCPv6 with Prefix delegation does not work together with PPPOE Server vice versa it is not possible to get a prefix with an interface where the IPv4 Uplink is PPPOE.</p> pfSense - Bug #9123 (Feedback): Adding/configuring vlan on ixl-devices causes aq_add_macvlan err ...https://redmine.pfsense.org/issues/91232018-11-15T10:50:14ZSebastian Deuerling
<p>The actual vlan addition/configuring process is triggering error "aq_add_macvlan err -53, aq_error 14" on ixl-devices.<br />Configuring vlans seems to work nevertheless, but saving interface configurations with vlans takes a lot of time.<br />In our setup (two igb-interfaces, two ix-interfaces, two ixl-interfaces; 25 vlans on failover-lagg of ixl0 and igb0) saving changes on interface configuration lasts around about 20 to 30 minutes. After that pfSense seems to freeze. After reboot all vlans are working.<br />But booting also takes a lof of time. Around 5 minutes in step "Configuring VLANS...".<br />Our hardware: SYS-5018D-FN4T (Supermicro Intel Xeon D-1541 system) and X710DA2BLK (Intel X710-DA2 Dual-SFP+-PCIe-Addon-cards).<br />Further information here: <a class="external" href="https://forum.netgate.com/topic/136201/new-version-2-4-4-interface-error-aq_add_macvlan-err-53-aq_error-14/14">https://forum.netgate.com/topic/136201/new-version-2-4-4-interface-error-aq_add_macvlan-err-53-aq_error-14/14</a></p> pfSense - Bug #8964 (New): IPsec async cryptography advanced setting - TCP traffic not passing t...https://redmine.pfsense.org/issues/89642018-09-27T02:25:33ZVladimir Lind
<p>Test setup:</p>
<p>Windows <-> SG2220 2.4.4-rel <---IPSEC---> SG3100 2.4.4-rel <-> Windows</p>
<p>IPsec (tunnel mode) with following settings:<br />P1 - mode Auto, AES128, SHA256, DH14<br />P2 - AES128GCM, no hash, PFS 14</p>
<p>ICMP between Win hosts is OK.<br />But SMB traffic is not going through with Async Crypto enabled on any side. I do see established TSP session. When I disable async crypto - SMB download immediately begin to flow.<br />Attached a packet dump sniffed on LAN of the 3100 - it is a snippet of the moment when async was disabled (lines 12-15) and SMB began to work.</p>
<p>Please refer also to trouble tickets 12812 and 12864 for additional details.</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>