pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162024-02-21T03:59:00ZpfSense bugtracker
Redmine pfSense - Todo #15277 (New): Allow mixed source (URL (IPs), URL Table (IPs), Host(s) and Network(...https://redmine.pfsense.org/issues/152772024-02-21T03:59:00ZSergei Shablovsky
<p>Dear Brilliant pfSense DevTeam!</p>
<p>WHERE<br />in Firewall / Aliases</p>
<p>ARGUMENT <br />From firewall and user perspective there are two possible aliases:<br />- aliases for ports;<br />- aliases for IPs;<br />and pfSense make ability to entering both MANUALLY or AUTOMATICALLY by parsing the source (in PLAIN TXT, XML, JSON) himself.<br />And pfSense have WebGUI for entering this both.</p>
<p>From user perspective THE ALIASES ARE LOGICAL OBJECT TO GROUPING the IPs and ports.</p>
<p>FROM USER PERSPECTIVE would be useful mixed source of one type (for example URL (IPs), URL Table (IPs), Host(s) and Network(s) IN ONE ALIAS. <br />The same for Port(s), URL Port(s) and URL Table (Ports) - also IN ONE ALIAS.</p>
<p>EXAMPLE<br />Most external monitoring SaaS and servers/appliances manufacturers provide their services in a mixed form: FQDN + fixed IPs + fixed ports. <br />And if for ports LOGICALLY RIGHT to aggregate ports numbers in ONE ALIAS (for example StatusCake_PORT_MONITORING), for URLs would be also LOGICALLY RIGHT to aggregate IPs into ONE ALIAS (for example StatusCake_IP_MONITORING).</p>
<p>Page with example <a class="external" href="https://www.statuscake.com/kb/knowledge-base/what-are-your-ips/">https://www.statuscake.com/kb/knowledge-base/what-are-your-ips/</a></p>
<p>Otherwise pfSense user need to create 3(three!!!) separate aliases (URL (IPs), URL Table (IPs), Host(s)) for one service and after make + ANOTHER ONE alias for aggregating all 3(three) sources into one to using in pfSense firewall rules…<br />This significantly increase ability to mistyping/errors in process of rules configurations.</p>
<p>Thank You so much!</p> pfSense - Todo #15271 (New): Add information about group keys to Pushover notification settingshttps://redmine.pfsense.org/issues/152712024-02-20T07:04:07ZSergei Shablovsky
<p>Brilliant pfSense DevTeam!</p>
<p>Please Correct “User key” description in System/Advanced/Notification/Pushover</p>
<p>from <br />“Enter user key of the Pushover account”</p>
<p>to<br />“Enter User Key (to send notifications to particular Pushover User) or Group Key (to broadcast notifications to all users in a particular group).</p>
<p>Because the last changes in Pushover service.</p> pfSense - Todo #15184 (New): Change hint text in "Remote Log Servers" to reflect actual possible ...https://redmine.pfsense.org/issues/151842024-01-23T10:36:53ZSergei Shablovsky
<p>Dear pfSense Dev Team!</p>
<p>On a page<br /><strong>Status / System Logs / Settings</strong><br />Section<br />" <strong>Remote Logging Option</strong> " <br />UI Element<br />" <strong>Remote Log Servers</strong> "</p>
<p>In the input text field NOW there are hint<br />IP[:port]</p>
<p>Proposal to change this hint to<br />hostname/IP[:port]</p>
<p>to reflect "Remote Log Servers" section from official documentation<br /><a class="external" href="https://docs.netgate.com/pfsense/en/latest/monitoring/logs/remote.html">https://docs.netgate.com/pfsense/en/latest/monitoring/logs/remote.html</a><br /><em>Each remote server can use either an <strong>IP address or hostname</strong> , and an optional UDP port number.</em></p> pfSense - Todo #14958 (New): Always reinstall *-kmod packageshttps://redmine.pfsense.org/issues/149582023-11-09T13:09:44ZKristof Provost
<p>We should ensure that *-kmod packages (such as drm-510-kmod) always get reinstalled on upgrade.<br />These ports are kernel modules, and there is insufficient ABI stability between freebsd-src updates for them to reliably work when the kernel changes.</p>
<p>Reinstalling the packages ensures that we install a version built against the new kernel, even if the port itself hasn't changed.</p> pfSense - Todo #14359 (New): Reorganize Advanced Optionshttps://redmine.pfsense.org/issues/143592023-05-08T19:10:44ZJim Pingle
<p>The placement of several options under the various Advanced options tabs doesn't make much sense in current versions. Some are only at their current locations for historical reasons.</p>
<p>Some things should be moved, such as:</p>
<ul>
<li>Cryptographic and Thermal hardware - Split into two separate sections, no compelling reason to combine them these days.</li>
<li>Schedules - Move from Misc to Firewall & NAT tab since it's about killing states based on rule schedules</li>
<li>Gateway Monitoring - Move from Misc to Firewall & NAT tab since it's mostly about firewall states and rules based on gateway events/status.</li>
<li>Load Balancing - Move from Misc to Firewall & NAT tab since it's a pf gateway behavior option, also rename so it's more clear that it is for Multi-WAN.</li>
<li>Reset All States - Move from Networking Firewall & NAT tab since it's about resetting firewall states</li>
<li>Advanced Options section of Firewall & NAT tab, move to bottom of the page</li>
</ul>
<p>The Firewall & NAT page is getting rather long, however, so it may also be worth considering if that should be split into multiple tabs. For example the gateway bits could go on a Gateways & Multi-WAN tab.</p>
<p>It's all up for debate, but the current layout seems confusing for new users in various ways.</p> pfSense - Todo #14352 (New): Virtual IP address configuration input fields are handled inconsiste...https://redmine.pfsense.org/issues/143522023-05-05T15:48:38ZJim Pingle
<p>When editing a VIP, some options are enabled/disabled when changing types (e.g. Address Type, CARP Options) while others are hidden or shown based on type (Expansion). These should be made consistent so they are all shown or hidden only as needed for each type.</p>
<p>Also a good opportunity to clean up the form in general, for example:</p>
<ul>
<li>Move Description up to the top</li>
<li>Split CARP options into a separate form section</li>
<li>Group Address Type and Expansion into their own section for Proxy ARP/Other Type VIPs</li>
</ul>
<p>So it would end up with three sections:</p>
<ul>
<li>General: Description, Type, Address</li>
<li>Address Options (Only shown for Proxy ARP and Other): Address Type, Expansion</li>
<li>CARP Options (Only shown for CARP VIPs): VIP Password, VHID, Adv base/skew, CARP mode (Plus).</li>
</ul> pfSense - Todo #14210 (New): Proposed new Icons for Logs to make for more logical readinghttps://redmine.pfsense.org/issues/142102023-03-31T04:51:11ZJon Brown
<p>On the firewall logs (Status --> System Logs --> Firewall --> normal view) and probably elsewhere you use the following icons</p>
<ul>
<li>Green minus in box = Easy Rule: Add to Block List</li>
<li>Green plus in box = Easy Rule: Pass this traffic</li>
</ul>
<p><img src="https://redmine.pfsense.org/attachments/download/4874/old-firewall-icons.jpg" alt="" /></p>
<p>I find these icons confusing because '+' and '-' imply adding and removing from a list whereas both of these functions add to a list, either adding to a block list or adding to a pass list.</p>
<p>I propose using:</p>
<ul>
<li>a stop sign (minus in a circle) = Easy Rule: Add to Block List</li>
<li>an arrow in a box = Easy Rule: Pass this traffic</li>
</ul>
<p>The circle and square make it easier to distinguish between the two operations and their purpose. The stop sign implies blocking and is universal for this (definitely UK, US and Europe use this sign). The arrow in the box is also better that a plus because the arrow implies movement through.</p>
<p>See my example below (they are not supposed to be the final icons either just a quick mockup)</p>
<p><img src="https://redmine.pfsense.org/attachments/download/4875/new-firewall-icons.jpg" alt="" /></p> pfSense - Todo #13634 (New): Update default DHCPv6 rules to follow RFC8415https://redmine.pfsense.org/issues/136342022-11-07T09:32:12ZMarcos M
<p>The reason for updating these is to have "correct" rules by default. Anything that breaks RFC would potentially need its own user-created rule when the default rules have been changed.</p>
<ol>
<li>Following the previous commits, there rules were included as is seemingly as a precaution at best.</li>
<li>There were no references to examples of devices not following the basic RFC guidelines of ports.</li>
<li>Other multicast addresses are used for things like DHCPv6 failover which we have not implemented.</li>
<li>Ultimately, there are the default allow all rules for in/out so at worst the changes wouldn't break any default setups.</li>
</ol>
<p>Current rules are:<br /><pre>
# for the DHCPv6 client
pass in {$log['pass']} quick on \${$oc['descr']} proto udp from fe80::/10 port = 546 to fe80::/10 port = 546 ridentifier {$increment_tracker()} label "{$fix_rule_label("allow dhcpv6 client in {$oc['descr']}")}"
pass in {$log['pass']} quick on \${$oc['descr']} proto udp from any port = 547 to any port = 546 ridentifier {$increment_tracker()} label "{$fix_rule_label("allow dhcpv6 client in {$oc['descr']}")}"
# Add Priority to dhcp6c packets if enabled
pass out {$log['pass']} quick on \${$oc['descr']} proto udp from any port = 546 to any port = 547 ridentifier {$increment_tracker()} label "{$fix_rule_label("allow dhcpv6 client out {$oc['descr']}")}" {$vlantag}
# if DHCPv6 server or relay is enabled
pass {$log['pass']} quick on \${$oc['descr']} inet6 proto udp from fe80::/10 to fe80::/10 port = 546 ridentifier {$increment_tracker()} label "allow access to DHCPv6 server"
pass {$log['pass']} quick on \${$oc['descr']} inet6 proto udp from fe80::/10 to ff02::/16 port = 546 ridentifier {$increment_tracker()} label "allow access to DHCPv6 server"
pass {$log['pass']} quick on \${$oc['descr']} inet6 proto udp from fe80::/10 to ff02::/16 port = 547 ridentifier {$increment_tracker()} label "allow access to DHCPv6 server"
pass {$log['pass']} quick on \${$oc['descr']} inet6 proto udp from ff02::/16 to fe80::/10 port = 547 ridentifier {$increment_tracker()} label "allow access to DHCPv6 server"
# if an IPv6 address exists on the interface either from track-interface or statically assigned
pass in {$log['pass']} quick on \${$oc['descr']} inet6 proto udp from fe80::/10 to {$oc['ipv6']} port = 546 ridentifier {$increment_tracker()} label "allow access to DHCPv6 server"
pass out {$log['pass']} quick on \${$oc['descr']} inet6 proto udp from {$oc['ipv6']} port = 547 to fe80::/10 ridentifier {$increment_tracker()} label "allow access to DHCPv6 server"
</pre></p> pfSense - Todo #13537 (Feedback): Update vendor fileshttps://redmine.pfsense.org/issues/135372022-10-02T06:54:21ZGChuf 6
<p>Update jquery and jquery_ui</p>
<p><a class="external" href="https://github.com/pfsense/pfsense/pull/4618">https://github.com/pfsense/pfsense/pull/4618</a></p>
<p>Reasons for update:</p>
<p>jquery_ui v1.13.0:<br /><em>Usage of deprecated jQuery APIs have been removed, 3 security issues fixed, ...</em><br /><a class="external" href="https://blog.jqueryui.com/2021/10/jquery-ui-1-13-0-released/">https://blog.jqueryui.com/2021/10/jquery-ui-1-13-0-released/</a></p>
<p>jquery v3.6.0:<br /><em>Bug fixes and improvements</em><br /><a class="external" href="https://blog.jquery.com/2021/03/02/jquery-3-6-0-released/">https://blog.jquery.com/2021/03/02/jquery-3-6-0-released/</a></p> pfSense - Todo #13508 (In Progress): Uncouple RAM Disk size from available kernel memoryhttps://redmine.pfsense.org/issues/135082022-09-22T09:28:09ZSteve Wheeler
<p>Now that we are building RAM disks with tmpfs the size is no longer restricted by the available kernel memory but we are till checking for that and limiting the size.</p>
<p>This is only significant in armv7 and really only the 3100 where kernel memory is limited but does apply to all architectures.</p> pfSense - Todo #13263 (Feedback): Reduce log spam when deleting a static DHCP entryhttps://redmine.pfsense.org/issues/132632022-06-10T10:55:17Z→ luckman212luke.hamburg@gmail.com
<p>This is not a huge priority, but when deleting static DHCP mappings for devices that are offline / not on network and thus not in arp cache, the log will be filled with</p>
<pre>
/services_dhcp_edit.php: The command '/usr/sbin/arp -d '192.168.20.60" returned exit code '1', the output was 'arp: writing to routing socket: No such file or directory'
</pre>
<p>Simply piping the output of that <code>arp -d</code> command to <code>/dev/null</code> should solve this and reduce log spam.</p>
<p>Example screenshot:</p>
<p><img src="https://redmine.pfsense.org/attachments/download/4282/clipboard-202206101152-yqi0i.png" alt="" /></p> pfSense - Todo #10199 (New): Improve Spanish translation interfacehttps://redmine.pfsense.org/issues/101992020-01-22T09:20:34ZAluisco Miguel Ricardo MastrapapfSense - Todo #6727 (New): Missing file apple-touch-icon-precomposed.png ?https://redmine.pfsense.org/issues/67272016-08-18T14:10:11ZAndy Kniveton
<p>I notice this occasionally in my log files after logging in via the web browser :-</p>
<p>Aug 18 19:50:38 pfsense.localdomain nginx: 2016/08/18 19:50:38 [error] 36942#100114: *10595 open() "/usr/local/www/apple-touch-icon-precomposed.png" failed (2: No such file or directory), client: 172.16.1.20, server: , request: "GET /apple-touch-icon-precomposed.png HTTP/1.1", host: "172.16.1.1"</p>
<p>[2.3.2-RELEASE][<a class="email" href="mailto:admin@pfsense.localdomain">admin@pfsense.localdomain</a>]/root: ls /usr/local/www/apple-touch-icon-precomposed.png<br />ls: /usr/local/www/apple-touch-icon-precomposed.png: No such file or directory</p>
<p>[2.3.2-RELEASE][<a class="email" href="mailto:admin@pfsense.localdomain">admin@pfsense.localdomain</a>]/root: ls /usr/local/www/*.png<br />/usr/local/www/apple-touch-icon.png/usr/local/www/logo.png<br />/usr/local/www/logo-black.png /usr/local/www/pfs-mini.png<br />[2.3.2-RELEASE][<a class="email" href="mailto:admin@pfsense.localdomain">admin@pfsense.localdomain</a>]/root:</p>
<p>Maybe its just worth doing a symbolic link in the next pfSense build.</p> pfSense - Todo #6697 (New): White squares around the numeric values in the Status / Queues pagehttps://redmine.pfsense.org/issues/66972016-08-13T07:46:19ZAndy Kniveton
<p>White squares around the numeric values in the Status / Queues page, I've tried Safari & Firefox, both show the same.</p> pfSense - Todo #5480 (New): inconsistent display of default values in fieldshttps://redmine.pfsense.org/issues/54802015-11-18T17:20:41ZJared Dillardjdillard@netgate.com
<p>Feedback from a user:</p>
<blockquote>
<p>One thing I noticed is that the UI is inconsistent with the display of default values in fields. It's not a new issue, but since one of the goals of 2.3 is to clean up the UI, it's a good time to fix it.<br />In some cases the default is already in the field as if the user put it there (Max Processes).<br />In other cases the default is shown grayed out if the field hasn't been modified by the user (SSH port).<br />Finally, sometimes it's just empty even if there's a default value, and the default is discussed in the description.<br />My preference would be to show the default grayed out if the field hasn't been modified by the user, like it is with the SSH port. But anything would be acceptable as long as it's consistent.</p>
</blockquote>