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 #14264 (New): Consider lowering default session timeout from current default of fo...https://redmine.pfsense.org/issues/142642023-04-10T10:01:11ZJim Pingle
<p>The current session timeout is 240 minutes (four hours), but it might be time to lower that a bit. Current concerns with session hijacking make that seem like a larger window than it should be by default.</p>
<p>It's hard to say what the most optimal secure value here is without irritating the user, but it may be at least enough to cut it in half (two hours, 120 minutes) and see what the user experience is like.</p>
<p>Users are always free to change the value as they see fit (System > User Manager, Settings tab) so anyone with immediate concerns can lower it themselves now, and if someone finds whatever the new default value is too short, they could raise it themselves as well.</p> 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 #13592 (New): Clarify Hardware TCP Segmentation Offloading optionhttps://redmine.pfsense.org/issues/135922022-10-24T13:21:43ZMarcos M
<p>Under <code>System / Advanced / Networking</code>, the option <code>Disable hardware TCP segmentation offload</code> is checked by default. In the system tunables page, <code>net.inet.tcp.tso</code> is set to <code>1</code>. Running <code>ifconfig -vvvma</code> shows the option is not set; the tunable should be changed to 0 to match the default behavior.</p> pfSense - Todo #13414 (New): IPsec: Phase 1 Delay advanced option does not include scale or type ...https://redmine.pfsense.org/issues/134142022-08-13T18:58:06ZPat Jensen
<p>The description for dead peer detection delay does not include the type of timer, or the scale. This makes it difficult to understand, configure or troubleshoot.</p>
<p>It should match the same design langauge as the Expiration timers listed above it in the Phase 1 configuration.</p>
<p>Setting is currently labeled:<br />Delay between sending peer acknowledgement messages. In IKEv2, a value of 0 sends no additional messages and only standard messages (such as those to rekey) are used to detect dead peers.</p>
<p>Setting should be labeled similarly:<br />Time, in seconds, between sending peer...</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 #12367 (New): ZFS: Do not show memstick disk on target listhttps://redmine.pfsense.org/issues/123672021-09-13T07:37:17ZRenato Botelhorenato@netgate.com
<p>As we did for UFS in the past, do not present memstick device used to boot install as an option of target disk for user to select. On attached screenshot da1 is the media used to boot</p> pfSense - Todo #12176 (Pull Request Review): Hide WireGuard interfaces on appropriate pageshttps://redmine.pfsense.org/issues/121762021-07-30T00:55:50ZViktor Gurov
<p>Todo:<br />1) Add <code>tun_wg</code> to <code>is_pseudo_interface()</code> list to prevent its use on the DHCP/DHCP6 Relay (<a class="issue tracker-2 status-3 priority-4 priority-default closed" title="Feature: Exclude unsupported interfaces from DHCP Relay (Resolved)" href="https://redmine.pfsense.org/issues/10341">#10341</a>) and PPPoE pages (<a class="issue tracker-1 status-3 priority-4 priority-default closed" title="Bug: Crash & reboot loop when configure PPPoE server on PPPoE client interface (Resolved)" href="https://redmine.pfsense.org/issues/4510">#4510</a>), Bridge prio/cost (<a class="issue tracker-1 status-3 priority-4 priority-default closed" title="Bug: Bridge STP priority/cost error (Resolved)" href="https://redmine.pfsense.org/issues/11122">#11122</a>) and hide the interface MAC address field (<a class="issue tracker-1 status-3 priority-4 priority-default closed" title="Bug: Interfaces page displays MAC Address field for interfaces which do not support L2 (Resolved)" href="https://redmine.pfsense.org/issues/11387">#11387</a>)<br />2) Hide it on the DHCP/DHCPv6 pages (see <a class="issue tracker-4 status-6 priority-4 priority-default closed" title="Todo: Error after enable DHCP on Wiregurd (Rejected)" href="https://redmine.pfsense.org/issues/12175">#12175</a>)<br />3) Hide it on the VLAN/QinQ pages</p> pfSense - Todo #8743 (New): Gateway Groups page should list gateways in tier orderhttps://redmine.pfsense.org/issues/87432018-08-03T10:21:15ZMitch Claborn
<p>The Gateway Groups page (system_gateway_groups.php) lists gateways within a group in alpha order. I think it makes more sense to list them in Tier order.</p> pfSense - Todo #6390 (New): Autoscale from Traffic Graph not correct size (big graphs)https://redmine.pfsense.org/issues/63902016-05-23T01:36:00ZManuel M.manuel.michalski@me.com
<p>Hey guys</p>
<p>The autoscale feature from the traffic graph is too big. Attached is a screeshot, where your can see what I mean ;)</p> pfSense - Todo #5902 (New): Use a common place for default valueshttps://redmine.pfsense.org/issues/59022016-02-17T06:10:35ZPhillip Davisphil@jankaritech.com
<p>Currently the default value of many settings is used in the backend code that implements something, and is also in the text of the help message, and might be in other "front-end" validation code that runs when the settings are saved. Having a default setting (e.g. number) used literally in 3 different places leads to it getting out-of-sync when the default is changed.<br />Put all default values (and other "constants") into include files. Use the values from the include files everywhere. That way the system stays consistent when default values are changed.</p> pfSense - Todo #2099 (New): Remove "queue" from CARP traffichttps://redmine.pfsense.org/issues/20992012-01-17T03:00:19ZMichele Di Mariamichele@nt2.it
<p>Hello,<br /> as it happened for the "Outbound NAT", there's the possibility that the CARP traffic can be matched by one of the rules in the "Floating Rules" (For example: Interface: LAN, source: ANY). This brings, under heavy traffic, to loose some of the CARP packets, which causes CARP to promote the secondary machine as master.</p>
<p>What could be done is to create a static rule just after the "floating rules" that matches all the CARP traffic and removes the queue (but I don't know if it's possible).</p> pfSense - Todo #1940 (New): Integrate rSyslogdhttps://redmine.pfsense.org/issues/19402011-10-08T07:14:02ZErmal Luçieri@pfsense.org
<p>Seems its a better alternative to syslog since it supports encryption and can secure communication.<br /><a class="external" href="http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/rsyslog5/pkg-descr?rev=1.7">http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/rsyslog5/pkg-descr?rev=1.7</a></p>