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 #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 #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 #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 #13159 (New): Decrease distance between img-buttons in webGUI to eliminate mistake...https://redmine.pfsense.org/issues/131592022-05-12T21:15:09ZSergei Shablovsky
<p>Hi, dear pfSense Dev Team!</p>
<p>Please, decrease distance between img-buttons in “Action” column in most webGUI pages to eliminate mistake entry, especially when pfSense remotely accessed from iPad (or any same size tablet) or 15-16-17” notebook that mostly used by SysAdmins nowadays.</p>
<p>Because so easy to tap on wrong image-button, so SysAdmin need constantly making pinch-in/pinch out. Very annoying design mistake...Sorry</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 #12025 (New): Add 1:1 Validation to Notify Someone They are 1:1 NAT'ing an Interfa...https://redmine.pfsense.org/issues/120252021-06-10T17:34:03ZKris Phillips
<p>Although it is VERY rarely necessary, we should add a banner to the top of the 1:1 NAT page notifying end users that they have just 1:1 NAT'ed the WAN interface address and this is usually not recommended due to connectivity issues for dpinger, IPSec, etc. that may occur. Often we see users 1:1 NAT their WAN address out of lack of experience/understanding. Additionally, this should be useful if there was a way to verify against an HA member as well or CARP VIP as it can sometimes be easy to forget that your secondary unit is using the 1:1 NAT address you just configured on the primary and pushed it to the secondary (which then causes gateway monitoring to fail on that interface).</p> pfSense - Todo #11280 (New): Add WireGuard to ALTQ listhttps://redmine.pfsense.org/issues/112802021-01-21T15:31:31ZJim Pingle
<p>wg interfaces support ALTQ, so can be added to the list.</p> pfSense - 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 #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>