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 #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 #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 #14260 (New): Change “IP[:PORT]” to “IP / FQDN[:PORT]https://redmine.pfsense.org/issues/142602023-04-09T17:18:31ZSergei Shablovsky
<p>Hi!</p>
<p>In System Logs -> Settings page in Remote Log Servers section:</p>
<p>Change “IP[:PORT]” to “FQDN or IP [:PORT] in grayed suggestion inside field.</p> pfSense - Todo #14190 (Pull Request Review): Update nvd3 (web ui dependency) to 1.8.6https://redmine.pfsense.org/issues/141902023-03-28T02:56:36ZGChuf 6
<p>Updates and minifies nvd3 for better performance and some bug fixes.</p>
<p>PR: <a class="external" href="https://github.com/pfsense/pfsense/pull/4629">https://github.com/pfsense/pfsense/pull/4629</a></p> pfSense - Todo #13899 (New): Unclear description for UPnP option Override WAN addresshttps://redmine.pfsense.org/issues/138992023-01-24T14:52:42ZMarcos M
<p>The description is currently:</p>
<blockquote>
<p>Use an alternate WAN address to accept inbound connections, such as an IP Alias or CARP Virtual IP address.</p>
</blockquote>
<p>This makes it sound like the field supports aliases which it does not. It could instead simply state:</p>
<blockquote>
<p>Use an alternate IP address to accept inbound connections.</p>
</blockquote> pfSense - Todo #13644 (In Progress): Enable ALTQ support in cxgbe(4)https://redmine.pfsense.org/issues/136442022-11-09T14:50:15ZSteve Wheeler
<p>The cxgbe(4) driver is shown in documentation as supporting ALTQ but the code there appears to have had that removed as far back as 2012.</p>
<p>The pfSense input error checking shows it as supported and allows selecting cxgbe interface types for traffic shaping. The results in an unloadable ruleset.</p>
<p>There are a number of previous tickets relating to this where support for cxgbe interface types was added to pfSense but it appears it could never have worked.</p>
<p>ALTQ support should be added ideally. If it cannot be the cxgbe NICs should be removed from the supported interface list to prevent creating a bad ruleset.</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 #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 #13058 (New): Add static routes and directly connected networks back to policy rou...https://redmine.pfsense.org/issues/130582022-04-13T08:05:33ZJim Pingle
<p>The <code>negate_networks</code> list for automatic policy route negation rules used to include VPNs, static routes, and directly connected networks. It was adjusted at various points over the years as people felt it was passing more than users wanted, though. See <a class="issue tracker-5 status-1 priority-4 priority-default" title="Correction: Negate Rules function does not match the description (New)" href="https://redmine.pfsense.org/issues/12535">#12535</a> for part of that. At some point after the static route and direct network parts were removed, the logic on the rules was fixed so they wouldn't pass more than intended but the content was never put back the way it was.</p>
<p>We should bring back the original intent of the behavior. It should go back to including static route and directly connected networks. Since the code only triggers on a destination of 'any' it should be safe these days.</p>
<p>We could make this configurable by the user. Currently there is an option to disable the negation rules entirely but it could be a multiple choice:</p>
<ul>
<li>VPNs, static routes, and directly connected networks</li>
<li>VPNs only</li>
<li>Satic routes and directly connected networks only</li>
<li>Disable</li>
</ul>
<p>And on upgrade it could map unset=disabled, and set=VPNs only.</p> pfSense - Todo #12459 (New): Add IP Alias subnet input validationhttps://redmine.pfsense.org/issues/124592021-10-15T09:35:08ZViktor Gurov
<p>From <a class="external" href="https://docs.netgate.com/pfsense/en/latest/firewall/virtual-ip-address-comparison.html#ip-alias">https://docs.netgate.com/pfsense/en/latest/firewall/virtual-ip-address-comparison.html#ip-alias</a>:<br />- Can be in a <strong>different subnet than the real interface IP address when used directly on an interface</strong> .<br />- <strong>Subnet mask should match the interface IP, or /32</strong> . Matching the interface subnet is best. For IP addresses in different subnets at least one IP alias VIP must have the correct mask for the new subnet.<br />- Stacked IP Alias VIPs <strong>must be inside the same subnet as the CARP VIP</strong> upon which they are placed.</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 #12243 (New): Implement ```plugin_interfaces()``` https://redmine.pfsense.org/issues/122432021-08-11T00:51:48ZViktor Gurov
<p>from <a class="external" href="https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/309#note_39017">https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/309#note_39017</a>:</p>
<p>The package should return an array with information about its interface like the prefix or regex pattern to match it, whether or not it supports ALTQ, whether or not it supports L2, VLANs (<code>is_pseudo_interface()</code>), and so on. <br />Any place that we might want to include or exclude it from a list should be controlled by the package data and not by hardcoding it.</p>
<p>Can be used by WireGuard (<a class="issue tracker-4 status-16 priority-4 priority-default" title="Todo: Hide WireGuard interfaces on appropriate pages (Pull Request Review)" href="https://redmine.pfsense.org/issues/12176">#12176</a>), Tinc VPN and OpenConnect (<a class="issue tracker-2 status-1 priority-4 priority-default" title="Feature: OpenConnect client (New)" href="https://redmine.pfsense.org/issues/8517">#8517</a>) packages</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>