pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162024-01-04T16:48:42ZpfSense bugtracker
Redmine pfSense - Bug #15140 (Incomplete): Remote syslog servers on dynamically routed networks are being...https://redmine.pfsense.org/issues/151402024-01-04T16:48:42ZJames Blanton
<p>Syslogd is started before any packages are started, including the FRR package. If any remote syslog servers are on a network whose route is learned over BGP, then this traffic will be routed to the default gateway initially. This is expected behavior, since the FRR package hasn't been loaded and no BGP routes have been received.</p>
<p>The problem is that the traffic is NOT being redirected after BGP routes are established due to the state that was created initially by routing the traffic through the default GW.</p>
<p>In my specific case, I've got a remote site sending syslog traffic over an OpenVPN tunnel with BGP routing between sites. When the remote router reboots, the syslog messages are routed out of the WAN interface, creating a state with an "src-org" of the LAN IP and "src" of the WAN IP. After the FRR package starts and the BGP routes are received, these messages continue to go out of the WAN interface until the state is killed.</p>
<p>I originally reported this bug with <a class="issue tracker-1 status-12 priority-4 priority-default closed" title="Bug: Syslog Over OpenVPN Routed Out Default GW On Reboot (Not a Bug)" href="https://redmine.pfsense.org/issues/14403">#14403</a>, but was told:</p>
<pre><code><em>This is a configuration issue -- if traffic is taking a path you don't want when the VPN is down, you need to add rules to block it (e.g. reject it outbound on WAN via floating rules).</em></code></pre>
<p>However, this does not work either. While it does prevent the traffic from exiting the WAN interface, the syslog messages are still not being routed properly after the BGP routes are received. This began occurring for me originally on 23.01, but is still occurring in 23.09.1.</p>
<p>I was able to get this working by adding some code in to the "/etc/rc.state_packages" script in the foreach loop that starts that packages that checks to see if the FRR package was just started, then looks to see if any remote syslog servers were configured. If there were any servers configured, then it sleeps for 15 seconds (to give time for the BGP peering to start) before looping through the servers and checking for any existing states. If any states exists, it checks for a "src-org" field and compares it to the "src" field. If the "src" and "src-org" don't match, then it kills that state. I have tested this change with 23.09.1, and it has been working as expected.</p> pfSense Packages - Bug #14861 (Incomplete): Telgraf package needs updating for for PHP 8.1 and hi...https://redmine.pfsense.org/issues/148612023-10-10T21:05:56ZDavid Bowen
<p>i was directed to report this issue here</p>
<p><a class="external" href="https://forum.netgate.com/topic/183151/telegraf-stopped-working-after-update-to-2-7/3">https://forum.netgate.com/topic/183151/telegraf-stopped-working-after-update-to-2-7/3</a></p>
<p>i believe the required file is attached but if any further information is required please let me know.</p>
<p>cheers</p> pfSense Packages - Bug #14805 (Incomplete): when I changed Endpoint ip via webgui, but wiregaurd ...https://redmine.pfsense.org/issues/148052023-09-23T06:33:08Zyon Liuinfo@ipv6china.com
<p>when I changed Endpoint ip via webgui, but the wiregaurd still using old Endpoint ip ruuning.</p> pfSense - Bug #14651 (Incomplete): pfSense 2.7.0 Release has PPPoE bug. Unable to even make conne...https://redmine.pfsense.org/issues/146512023-08-05T09:22:36ZCin Lung Chen
<p>Sorry if this is wrong, I am frustrated and would love to be pointed to the right direction. I made a post in the forum with no one that can help as follow: <a class="external" href="https://forum.netgate.com/topic/181990/pppoe-connection-over-vlan-does-not-work-after-upgrade-to-2-7-0-tonight-please-help/3">https://forum.netgate.com/topic/181990/pppoe-connection-over-vlan-does-not-work-after-upgrade-to-2-7-0-tonight-please-help/3</a></p>
<p>TLDR:<br />PPPoE canoot start, not event trying to negotiate with the server. I am not sure what to do since version 2.6.0 works. I did clean reinstall with the image taken from the web for serial connection version and it was still failed the similar log as follow:</p>
<p>Aug 4 21:50:38 ppp 36066 [wan_link0] LCP: Down event --> After this, everyhing will be repeated for eternity from PPPoE: Connecting to XXXX to LCP: Down event.<br />Aug 4 21:50:38 ppp 36066 [wan_link0] Link: DOWN event<br />Aug 4 21:50:38 ppp 36066 [wan_link0] PPPoE connection timeout after 9 seconds<br />Aug 4 21:50:29 ppp 36066 [wan_link0] PPPoE: Connecting to 'XXXXX'<br />Aug 4 21:50:29 ppp 36066 [wan_link0] LCP: LayerStart<br />Aug 4 21:50:29 ppp 36066 [wan_link0] LCP: state change Initial --> Starting<br />Aug 4 21:50:29 ppp 36066 [wan_link0] LCP: Open event<br />Aug 4 21:50:29 ppp 36066 [wan_link0] Link: OPEN event<br />Aug 4 21:50:29 ppp 36066 [wan] Bundle: Interface ng0 created</p> pfSense Packages - Bug #14284 (Incomplete): Wen changing frontend type, there will be invissible ...https://redmine.pfsense.org/issues/142842023-04-17T14:04:16ZLouis B
<p>During my trails to setup HA-proxy, I irregularly met a situation where I did not know which frontend type to use.<br />So I switch between types. And then there is a problem</p>
<p>Wen changing front-end type, there will be invisible leftovers, disturbing defining the new type.</p>
<p>So after defining the new chosen type the correct way, there were never the less errors due to now invisible settings from a version tried before.<br />The only way to fix that, is to delete the front-end and define it from the start.</p>
<p>This is not dramatic, but not ok as well :)</p> pfSense Packages - Feature #14196 (Incomplete): permitted firewall rules - additional texthttps://redmine.pfsense.org/issues/141962023-03-28T13:50:09ZJon Brown
<p>Firewall --> pfBlockerNG --> DNSBL --> DNSBL Configuration --> Permit Firewall Rules</p>
<p>Can you add some additional information here for the end user to explain lan segment and some possible scenarios when you would use this option.</p>
<p><a class="external" href="https://networkencyclopedia.com/lan-segment/">https://networkencyclopedia.com/lan-segment/</a> - Lan Segment is a physical portion of a local area network (LAN) that is separated from other portions by bridges or routers.</p>
<p><a class="external" href="https://www.reddit.com/r/pfBlockerNG/comments/p9te6f/should_permit_firewall_rules_be_enabled_i_was/">https://www.reddit.com/r/pfBlockerNG/comments/p9te6f/should_permit_firewall_rules_be_enabled_i_was/</a> - This thread mentions that you do not need this option unless you have VLANs</p>
<p><img src="https://redmine.pfsense.org/attachments/download/4864/permitted-firewall-rules.png" alt="" /></p> pfSense Packages - Bug #13571 (Incomplete): Tailscale disconnection problemhttps://redmine.pfsense.org/issues/135712022-10-18T03:10:04Zfang xn
<p>pppoe dial-up network, Tailscale will fail to connect after redialing after disconnection, and needs to change the port to reconnect.</p> pfSense Plus - Bug #13530 (Incomplete): Remote Logging strange behaviorhttps://redmine.pfsense.org/issues/135302022-09-29T18:43:21ZMarcelo Cury
<p>My SG-3100 (22.05) is configured to send logs to a remote syslog server in my LAN on port 1514.</p>
pfsense remote logs configuration:
<ul>
<li>System Events</li>
<li>Firewall Events</li>
<li>DNS Events</li>
<li>DHCP Events</li>
<li>General Authentication Events</li>
<li>VPN Events</li>
<li>Gateway Monitor Events</li>
<li>Network Time Protocol Events</li>
</ul>
<p>It has been working fine for several days but today I noticed that the Firewall Events stopped ( <strong>filterlog</strong> ).<br />The problem didn't happen with other events such as <strong>dhcpd, dpinger, filterdns, php-fpm, dhclient, unbound</strong>...</p>
<p>I'm not sure what could have triggered the issue, but I fixed by going in <em>Status > System > Logs > Settings > Remote Logging Options</em> and clicked in <strong>Save</strong> .</p>
<p><code>2022-09-29T18:36:09.000-03:00 filterlog[41290]: 4,,,1000000103,mvneta2,match,block,in,4,0x0,,239,35008,0,none,6,tcp,40,91.191.209.198,x.x.x.x,47587,3474,0,S,1457975303,,1024,,<br />2022-09-29T18:36:18.000-03:00 filterlog[41290]: 4,,,1000000103,mvneta2,match,block,in,4,0x0,,45,28891,0,DF,6,tcp,52,123.160.221.63,x.x.x.x,48931,8410,0,S,1759706956,,65535,,mss;nop;wscale;nop;nop;sackOK<br />2022-09-29T18:36:26.000-03:00 filterlog[41290]: 4,,,1000000103,mvneta0,match,block,in,4,0x0,,241,43257,0,none,6,tcp,44,198.199.107.80,y.y.y.y,41585,46738,0,S,2466400818,,1024,,mss<br />2022-09-29T18:36:35.000-03:00 filterlog[41290]: 4,,,1000000103,mvneta0,match,block,in,4,0x0,,245,25298,0,none,6,tcp,44,78.128.113.158,y.y.y.y,45686,29828,0,S,1291403791,,1024,,mss<br />2022-09-29T18:36:42.000-03:00 filterlog[41290]: 4,,,1000000103,mvneta2,match,block,in,4,0x0,,238,19919,0,none,6,tcp,40,5.188.206.38,x.x.x.x,46182,19202,0,S,1628533656,,1024,,<br />2022-09-29T18:36:43.000-03:00 filterlog[41290]: 158,,,1644897877,mvneta1.10,match,pass,in,4,0x0,,64,1756,0,DF,6,tcp,60,192.168.10.4,50.17.133.142,45699,443,0,S,2029797087,,29200,,mss;sackOK;TS;nop;wscale<br />2022-09-29T18:36:47.000-03:00 filterlog[41290]: 158,,,1644897877,mvneta1.10,match,pass,in,4,0x0,,64,5909,0,DF,6,tcp,60,192.168.10.4,50.17.133.142,45700,443,0,S,405679345,,29200,,mss;sackOK;TS;nop;wscale<br />h1. *LAST FIREWALL EVENT ABOVE*<br />2022-09-29T18:36:49.000-03:00 dhcpd[49200]: Wrote 0 class decls to leases file.<br />2022-09-29T18:36:49.000-03:00 dhcpd[49200]: Server starting service.<br />2022-09-29T18:36:49.000-03:00 dhcpd[49200]: Sending on Socket/fallback/fallback-net<br />2022-09-29T18:36:49.000-03:00 dhcpd[49200]: Sending on BPF/mvneta1.100/00:08:a2:0c:c4:1c/192.168.255.248/29<br />2022-09-29T18:36:49.000-03:00 dhcpd[49200]: Listening on BPF/mvneta1.100/00:08:a2:0c:c4:1c/192.168.255.248/29<br />2022-09-29T18:36:49.000-03:00 dhcpd[49200]: Sending on BPF/mvneta1.10/00:08:a2:0c:c4:1c/192.168.10.0/27<br />2022-09-29T18:36:49.000-03:00 dhcpd[49200]: Listening on BPF/mvneta1.10/00:08:a2:0c:c4:1c/192.168.10.0/27<br />2022-09-29T18:36:49.000-03:00 dhcpd[49200]: Sending on BPF/mvneta1.20/00:08:a2:0c:c4:1c/192.168.20.0/24<br />2022-09-29T18:36:49.000-03:00 dhcpd[49200]: Listening on BPF/mvneta1.20/00:08:a2:0c:c4:1c/192.168.20.0/24<br />2022-09-29T18:36:49.000-03:00 dhcpd[49200]: Wrote 0 leases to leases file.<br />2022-09-29T18:36:49.000-03:00 dhcpd[49200]: Wrote 0 new dynamic host decls to leases file.<br />2022-09-29T18:36:49.000-03:00 dhcpd[49200]: Wrote 0 deleted host decls to leases file.<br />2022-09-29T18:36:49.000-03:00 dhcpd[49200]: All rights reserved.<br />2022-09-29T18:36:49.000-03:00 dhcpd[49200]: For info, please visit https://www.isc.org/software/dhcp/<br />2022-09-29T18:36:49.000-03:00 dhcpd[49200]: Database file: /var/db/dhcpd.leases<br />2022-09-29T18:36:49.000-03:00 dhcpd[49200]: Copyright 2004-2021 Internet Systems Consortium.<br />2022-09-29T18:36:49.000-03:00 dhcpd[49200]: Config file: /etc/dhcpd.conf<br />2022-09-29T18:36:49.000-03:00 dhcpd[49200]: Internet Systems Consortium DHCP Server 4.4.2-P1<br />2022-09-29T18:36:49.000-03:00 dhcpd[49200]: PID file: /var/run/dhcpd.pid<br />2022-09-29T18:36:49.000-03:00 dhcpd[49200]: For info, please visit https://www.isc.org/software/dhcp/<br />2022-09-29T18:36:49.000-03:00 dhcpd[49200]: All rights reserved.<br />2022-09-29T18:36:49.000-03:00 dhcpd[49200]: Copyright 2004-2021 Internet Systems Consortium.<br />2022-09-29T18:36:49.000-03:00 dhcpd[49200]: Internet Systems Consortium DHCP Server 4.4.2-P1<br />2022-09-29T18:38:54.000-03:00 dhcpd[49200]: DHCPACK on 192.168.10.13 to 08:00:23:f2:fa:1c via mvneta1.10<br />2022-09-29T18:38:54.000-03:00 dhcpd[49200]: DHCPREQUEST for 192.168.10.13 from 08:00:23:f2:fa:1c via mvneta1.10<br />2022-09-29T18:50:05.000-03:00 dpinger[58536]: NET_DHCP z.z.z.z: Alarm latency 10631us stddev 1319us loss 22%<br />2022-09-29T18:50:10.000-03:00 filterdns[55605]: Adding Action: pf table: plex_wans_ip host: a.a.a.a<br />2022-09-29T18:50:10.000-03:00 filterdns[55605]: merge_config: configuration reload<br />2022-09-29T18:50:24.000-03:00 php-fpm[447]: /index.php: Successful login for user 'admin_user' from: 192.168.255.254 (LDAP/rpi3)<br />2022-09-29T18:57:03.000-03:00 dhcpd[49200]: DHCPACK on 192.168.10.8 to a8:db:03:51:f4:fe via mvneta1.10<br />2022-09-29T18:57:03.000-03:00 dhcpd[49200]: DHCPREQUEST for 192.168.10.8 from a8:db:03:51:f4:fe via mvneta1.10</code></p> pfSense Plus - Bug #13497 (Incomplete): unbound process looks like stuck periodicallyhttps://redmine.pfsense.org/issues/134972022-09-16T01:16:46ZYaroslav Semenenko
<p>Hello,</p>
<p>I have Netgate 2100.<br />Unbound service is needed to restart sometimes due to it could not resolve public domain name.</p>
<p>Thanks,<br />Yaroslav</p> pfSense Packages - Bug #13444 (Incomplete): zabbix_proxy : cannot open "/var/log/zabbix-proxy/zab...https://redmine.pfsense.org/issues/134442022-08-25T08:05:31ZSteve Scotter
<p>Hi</p>
<p>I frequently come across this issue when trying to investigate why a Zabbix agent isn't communicating successfully with our Zabbix server.</p>
<p>When I navigate to <a class="external" href="https://pfsense-ip-address/status_logs_packages.php?pkg=Zabbix%20Proxy%205.0">https://pfsense-ip-address/status_logs_packages.php?pkg=Zabbix%20Proxy%205.0</a> I'm presented with the following (truncated) logs</p>
<pre>
Jul 15 03:09:00 queeg500 newsyslog[90148]: logfile turned over due to size>500K
zabbix_proxy [78631]: cannot open "/var/log/zabbix-proxy/zabbix_proxy.log": [13] Permission denied
zabbix_proxy [82116]: cannot open "/var/log/zabbix-proxy/zabbix_proxy.log": [13] Permission denied
*** Above lines repeated 50+ times ***
Jul 15 03:09:00 queeg500 newsyslog[90148]: logfile turned over due to size>500K
...
...
</pre>
<p>Logging appears to have stopped ~40 days ago.</p>
<p>Restarting the Zabbix proxy service (via <a class="external" href="https://pfsense-ip-address/status_services.php#">https://pfsense-ip-address/status_services.php#</a>) gets logging working again, however its a pain because I generally speaking I wanted to see the logs for the past to investigate the problem I'm dealing with at that specific time.</p>
<p>I suspect the issue is related to log rotation and file permissions based on the Permission denied error and that newsyslog is mentioned before and after the logging stops working.</p>
<p>Today, before I restart the service I checked who owned the log file...</p>
<pre>
[2.6.0-RELEASE][root@pfsense-ip-address]/root: ls -l /var/log/zabbix-proxy/
total 106
-rw------- 1 root wheel 80 Jul 15 03:09 zabbix_proxy.log
-rw------- 1 root wheel 29744 Jul 15 03:09 zabbix_proxy.log.0.bz2
-rw------- 1 root wheel 33193 Jun 6 13:47 zabbix_proxy.log.1.bz2
-rw------- 1 root wheel 34871 May 4 09:48 zabbix_proxy.log.2.bz2
</pre>
<p>After I restarted the service I checked again...<br /><pre>
[2.6.0-RELEASE][root@fsense-ip-address]/root: ls -l /var/log/zabbix-proxy/
total 110
-rw------- 1 zabbix zabbix 3218 Aug 25 13:42 zabbix_proxy.log
-rw------- 1 zabbix zabbix 29744 Jul 15 03:09 zabbix_proxy.log.0.bz2
-rw------- 1 zabbix zabbix 33193 Jun 6 13:47 zabbix_proxy.log.1.bz2
-rw------- 1 zabbix zabbix 34871 May 4 09:48 zabbix_proxy.log.2.bz2
</pre></p>
<p>Investigating further I found the contents of `/var/etc/newsyslog.conf.d/zabbix_proxy.log.conf` does indeed set the owner to root</p>
<pre>
# Automatically generated for package Zabbix Proxy 5.0. Do not edit.
/var/log/zabbix-proxy/zabbix_proxy.log root:wheel 600 7 500 * JC
</pre>
<p>I'll try and remember to check tomorrow but I suspect the files will be owned by root again after the (presumably) daily log rotation occurs.</p>
I haven't made any customizations to the pfsense box. The only other plugins installed are
<ul>
<li>open-vm-tools v10.1.0_5,1</li>
<li>openvpn-client-export v1.6_4</li>
<li>zabbix-agent5 v1.0.4_12</li>
<li>zabbix-proxy5 v1.0.4_12</li>
</ul>
<p>I compared `/var/etc/newsyslog.conf.d/zabbix_ <strong>agentd</strong> .log.conf` with `/var/etc/newsyslog.conf.d/zabbix_ <strong>proxy</strong> .log.conf`, both set the owners to root</p>
<p>I then checked the ownership of the agent's log files, to my surprize they're owned by Zabbix. I have <strong>not</strong> restarted the Zabbix <strong>agent</strong> service today</p>
<pre>
ls -l /var/log/zabbix-agent/
total 5
-rw-rw-r-- 1 zabbix zabbix 11450 Aug 15 11:49 zabbix_agentd.log</pre> pfSense Packages - Bug #13432 (Incomplete): ups driver will not starthttps://redmine.pfsense.org/issues/134322022-08-19T14:43:00ZScott Lampertscott@lampert.org
<p>I cannot get a USB-connected UPS to be recognized unless the nut usb driver is started with the "-u root" option.</p>
<p>Without the option:<br /><pre><code class="shell syntaxhl"><span class="nv">$ </span>/usr/local/sbin/upsdrvctl start
Network UPS Tools - UPS driver controller 2.7.4
Network UPS Tools - Generic HID driver 0.41 <span class="o">(</span>2.7.4<span class="o">)</span>
USB communication driver 0.33
No matching HID UPS found
Driver failed to start <span class="o">(</span><span class="nb">exit </span><span class="nv">status</span><span class="o">=</span>1<span class="o">)</span>
</code></pre><br />With the option:<br /><pre><code class="shell syntaxhl"><span class="nv">$ </span>/usr/local/sbin/upsdrvctl <span class="nt">-u</span> root start
Network UPS Tools - UPS driver controller 2.7.4
Network UPS Tools - Generic HID driver 0.41 <span class="o">(</span>2.7.4<span class="o">)</span>
USB communication driver 0.33
Using subdriver: CyberPower HID 0.4
</code></pre></p>
<p>The service script for nut at /usr/local/etc/rc.d/nut.sh does not include the "-u root" option and so it fails to detect any usb connected ups and simple outputs:<br /><pre>
Broadcast Message from root@pfsense
(no tty) at 15:12 EDT...
UPS UPS_NAME_HERE is unavailable
</pre><br />over and over.</p> pfSense - Bug #13215 (Incomplete): Allowed MAC/IP/Hostname traffic counts for authorized usershttps://redmine.pfsense.org/issues/132152022-05-25T03:03:52ZViktor Gurov
<p>This is due to rewriting pf tags.<br />CP rules must check <code>tagged</code> value on all steps.</p> pfSense - Bug #12878 (Incomplete): Traffic shaping by interface, route queue bandwidth inbound, o...https://redmine.pfsense.org/issues/128782022-02-28T03:10:25ZBlake Drayson
<p>Since upgrading to pfSense Plus 22.01 from the latest community edition, my by interface priority queue bandwidth has an odd bug. Link is 200 Mbit/s and is set to 190 to give appropriate overhead. However when the queue is active it limits the connection to around 100 Mbit/s disable the queue it works fine. Work around so far has been to add 100 Mbit/s to the bandwidth value of the root queue (so it is now set to 290). The downlink queue is working without issue and as expected. For additional info the link that is being shapped is a L2TP link over the top of the WAN link.</p> pfSense - Bug #12740 (Incomplete): panic: esp_input_cb: Unexpected address familyhttps://redmine.pfsense.org/issues/127402022-01-27T12:38:51ZJuraj Lutter
<p>On pfSense 21.05.02 I've started to get a panic with panic string:</p>
<pre>
esp_input_cb: Unexpected address family: xxx
</pre>
<p>Where xxx varies (248, 255, 127, 0, ...)</p>
<p>Hardware is Netgate 7100.</p>
<p>If crashdump is needed, it's available upon request.</p> pfSense Packages - Bug #11530 (Incomplete): ntopng 4.2 needs to be updated to 4.3, Bug when acces...https://redmine.pfsense.org/issues/115302021-02-24T22:17:00ZMax D
<p>On pfsense 2.5, installing ntopng from package manager ntop 0.8.13_9 which is 4.2 version of ntopng, after logging into ntopng, results in a corrupt web page when clicking on a host for details, this has been fixed in 4.3 by ntopng team.</p>
<p>I installed 4.3 manually from ntopng pfsense doc, and confirmed this resolves the issue.</p>