pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162023-12-04T19:32:00ZpfSense bugtracker
Redmine pfSense - Bug #15063 (Confirmed): vpn_openvpn_server.php: shows last used interface, after changi...https://redmine.pfsense.org/issues/150632023-12-04T19:32:00ZGrischa Zengel
<p>How to reproduce:<br />1. Create openvpn server with interface "WAN" and protocol "UDP on IPv4 only" <br />2. Save config and reopen it<br />3. Change to multihome and save config</p>
<p>Now there is still "WAN" at openVPN overview. It should be "ANY".</p> pfSense - Bug #14479 (New): unbound doing qname-minimisation when enabled in unbound gui.https://redmine.pfsense.org/issues/144792023-06-16T18:46:14ZJohnPoz _
<p>I have not checked 2.7 or 23.05 yet but this came up in a discussion here</p>
<p><a class="external" href="https://forum.netgate.com/post/1110945">https://forum.netgate.com/post/1110945</a></p>
<p>Seems unbound is now doing qname by default.. So if there is no setting in the conf for qname-minimisation it does it. By default this option in 2.6 is not enabled, but since no entry in the .conf file it is being done. With no way to turn it off without placing an entry in the custom box to set it to no.</p>
<p>Logic should be changed to allow for enable/disable qname from the gui. What it defaults doesn't matter really, but with current logic there is no way to actually turn it off.. And gui reads that it is off by default, but it really isn't since unbound defaults to doing it.</p> pfSense - Bug #13486 (New): stongswan attributes should be comma-separated instead of whitespace-...https://redmine.pfsense.org/issues/134862022-09-12T09:30:48ZAndreas W
<p>The strongswan docs mention that attribute lists need to be "specified as a comma-separated list": <a class="external" href="https://docs.strongswan.org/docs/5.9/plugins/attr.html#_attribute_types">https://docs.strongswan.org/docs/5.9/plugins/attr.html#_attribute_types</a><br />The pfSense UI is using whitespace-separated values and is using them as-is.</p>
<p>This leads to a broken IPSec configuration and is especially relevant since <a class="issue tracker-1 status-3 priority-4 priority-default closed" title="Bug: IKEv2 Mobile IPsec clients do not receive ``INTERNAL_DNS_DOMAIN`` (value ``25``) attribute (Resolved)" href="https://redmine.pfsense.org/issues/12975">#12975</a> - which lead to a broken DNS resolution on 22.05 for my setup.</p>
<p>This applies to all fields that support multiple values - I noticed the issue with <pre>dns_split</pre> and attribute 25 specifically.</p> pfSense - Bug #13386 (New): service is work: MRT_DEL_MFC; Errno(49): Can't assign requested addresshttps://redmine.pfsense.org/issues/133862022-07-31T09:45:54ZTorstein Eide
<p>The service looks to be unable to work properly.</p>
<p><code><br />Jul 31 15:17:37 igmpproxy 80356 MRT_DEL_MFC; Errno(49): Can't assign requested address<br />Jul 31 15:17:37 igmpproxy 80356 Removing MFC: 84.214.120.18 -> 224.0.54.178, InpVIf: 0<br />Jul 31 15:17:31 igmpproxy 80356 MRT_DEL_MFC; Errno(49): Can't assign requested address<br />Jul 31 15:17:31 igmpproxy 80356 Removing MFC: 84.214.120.10 -> 224.0.54.91, InpVIf: 0<br />Jul 31 15:17:31 igmpproxy 80356 MRT_DEL_MFC; Errno(49): Can't assign requested address<br />Jul 31 15:17:31 igmpproxy 80356 Removing MFC: 84.214.120.10 -> 224.0.54.87, InpVIf: 0<br />Jul 31 15:17:26 igmpproxy 80356 The IGMP message was local multicast. Ignoring.<br />Jul 31 15:17:26 igmpproxy 80356 Inserted route table entry for 224.0.54.178 on VIF #-1<br />Jul 31 15:17:22 igmpproxy 80356 MRT_DEL_MFC; Errno(49): Can't assign requested address<br />Jul 31 15:17:22 igmpproxy 80356 Removing MFC: 84.214.120.26 -> 224.0.54.106, InpVIf: 0<br />Jul 31 15:17:22 igmpproxy 80356 MRT_DEL_MFC; Errno(49): Can't assign requested address<br />Jul 31 15:17:22 igmpproxy 80356 Removing MFC: 84.214.120.26 -> 224.0.54.58, InpVIf: 0<br />Jul 31 15:17:15 igmpproxy 80356 Inserted route table entry for 224.0.54.91 on VIF #-1<br />Jul 31 15:17:12 igmpproxy 80356 Inserted route table entry for 224.0.54.87 on VIF #-1<br />Jul 31 15:17:08 igmpproxy 80356 Inserted route table entry for 224.0.54.106 on VIF #-1<br />Jul 31 15:17:04 igmpproxy 80356 Inserted route table entry for 224.0.54.58 on VIF #-1<br />Jul 31 15:16:52 igmpproxy 80356 MRT_DEL_MFC; Errno(49): Can't assign requested address<br />Jul 31 15:16:52 igmpproxy 80356 Removing MFC: 84.214.120.18 -> 224.0.54.194, InpVIf: 0<br />Jul 31 15:16:46 igmpproxy 80356 The IGMP message was local multicast. Ignoring.<br />Jul 31 15:16:43 igmpproxy 80356 Inserted route table entry for 224.0.54.194 on VIF #-1<br />Jul 31 15:16:32 igmpproxy 80356 MRT_DEL_MFC; Errno(49): Can't assign requested address<br />Jul 31 15:16:32 igmpproxy 80356 Removing MFC: 84.214.120.10 -> 224.0.57.38, InpVIf: 0<br />Jul 31 15:16:26 igmpproxy 80356 The IGMP message was local multicast. Ignoring.<br />Jul 31 15:16:19 igmpproxy 80356 Inserted route table entry for 224.0.57.38 on VIF #-1<br />Jul 31 15:15:45 igmpproxy 80356 The IGMP message was local multicast. Ignoring.<br />Jul 31 15:15:26 igmpproxy 80356 The IGMP message was local multicast. Ignoring.<br />Jul 31 15:15:00 igmpproxy 80224 Joining group 224.0.0.22 on interface igc1<br />Jul 31 15:15:00 igmpproxy 80224 Joining group 224.0.0.2 on interface igc1<br />Jul 31 15:15:00 igmpproxy 80224 adding VIF, Ix 1 Fl 0x0 IP 0x0102a8c0 igc1, Threshold: 1, Ratelimit: 0<br />Jul 31 15:15:00 igmpproxy 80224 adding VIF, Ix 0 Fl 0x0 IP 0xc735d354 igc0, Threshold: 1, Ratelimit: 0<br /></code></p> pfSense - Bug #13252 (New): reduce frequency of php-fpm socket connection attempts from check_rel...https://redmine.pfsense.org/issues/132522022-06-06T13:06:48ZRoyce Williamsroyce@tycho.org
<p>When troubleshooting an issue, I discovered that my system logs were rotating every couple of minutes, due to many of these log entries being generated per second:</p>
<pre>
May 31 12:56:34 zeb check_reload_status[576]: Could not connect to /var/run/php-fpm.socket
[64 messages in the same second omitted]
May 31 12:56:34 zeb check_reload_status[576]: Could not connect to /var/run/php-fpm.socket
</pre>
<p>I am not sure what the root cause of this, but it appears to be within the Upgrade category.</p>
<p>If it's possible to reduce the frequency of this, that could help some users in the future.</p> pfSense - Bug #12547 (Feedback): unsheduled system reboot/crashhttps://redmine.pfsense.org/issues/125472021-11-28T07:19:02ZEvgeny Korostelev
<p>pfSense Community Edition 2.5.2<br />Try navigate to menu "Diagnostics" -> "Routes" <br />Then system crash/reboot, and after boot have text system dump (attached to report)</p> pfSense - Bug #10833 (New): unbound exits on configuration error when link status flaps on LAN in...https://redmine.pfsense.org/issues/108332020-08-13T23:53:30ZJohn Hood
<p>I have pfSense installed at home on a small, old, core2duo-based machine. It does pretty typical home-router duty; the most obvious-to-me unusual parts of the configuration are that the internal IPv4 network is 198.206.215.0/24 instead of an RFC1918 network address, and I have an IPv6 tunnel to Hurricane Electric.</p>
<p>This week, the 11-year-old unmanaged GbE switch attached to the LAN port got flaky, and started to fail in some way that caused it to blink all lights on the front and stop passing traffic. Logs show link status flapping on the LAN interface. On power-cycling the switch, it would start working again. But DNS service was gone, though restartable at Status/Services/unbound. I found this in resolver.log:</p>
<pre>
Aug 13 20:28:22 router unbound: [27434:0] fatal error: Could not read config file: /unbound.conf. Maybe try unbound -dd, it stays on the commandline to see more errors, or unbound-checkconf
</pre>
<p>I wrote a little monitoring script that does 'pgrep unbound' and 'ifconfig em1' every 10 seconds. That seems to show link flapping between normal:</p>
<pre>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
</pre><br />and no link:<br /><pre>
media: Ethernet autoselect
status: no carrier
</pre>
<p>It also showed two copies of dhcpleases running after the link starts flapping.</p>
<p>Edited/excerpted logs and the monitoring script are attached, the switch starts flapping at Aug 13 20:27:57 in the logs, and I power-cycled the switch about 20:28:45. I restarted unbound at 20:30:36.</p>
<p>I tried reproducing the problem by manually plugging/unplugging the patch cable involved, and was not able to reproduce the problem. Alas, I destroyed the switch by plugging the wrong power supply in, so it's no longer helpful either. So I have no repro. I suspect connecting a FreeBSD box and running a little script that did things with 'ifconfig down' and 'ifconfig up' and 'ifconfig mediaopt <blah>' combined with some randomized short delays would eventually knock unbound over.</p>
<p>I haven't investigated the code at all, but it smells like some kind of race condition in the link-configuration scripts to me.</p> pfSense - Bug #9737 (New): traffic-graphs.js shows incorrect units inside the charthttps://redmine.pfsense.org/issues/97372019-09-09T06:35:19ZAlex Kolesnikpfsenseorg3@temp.spb.ru
<p><a class="external" href="https://github.com/pfsense/pfsense/blob/42839d824d51cad3a8a55fccb2dc96368568ce8e/src/usr/local/www/js/traffic-graphs.js#L204">https://github.com/pfsense/pfsense/blob/42839d824d51cad3a8a55fccb2dc96368568ce8e/src/usr/local/www/js/traffic-graphs.js#L204</a></p>
<p>that condition doesn't work (at least) in Chrome - window.size returns a string literal instead of a number.</p> pfSense - Bug #8611 (In Progress): unable to receive IPv6 RA's on SG-1000, default route losthttps://redmine.pfsense.org/issues/86112018-06-30T16:44:03ZAnthony Roberts
expected behavior:
<ul>
<li>IPv6 default route is stable indefinitely</li>
</ul>
actual behavior:
<ul>
<li>IPv6 default route is lost a few minutes after release/renew</li>
<li>WAN interface still has IPv6 address</li>
<li>LAN interface still has /64</li>
<li>pfsense router has no default route, so it is impossible to route IPv6 traffic</li>
</ul>
configuration:
<ul>
<li>residential comcast connection</li>
<li>SG-1000 running 2.4.3-RELEASE-1 (arm)</li>
<li>WAN interface (cpsw0) configured for DHCPv4, DHCPv6-PD</li>
<li>LAN interface (cpsw1) configured to track WAN for PD</li>
</ul>
investigation:
<ul>
<li>attempted to run tcpdump on WAN interface</li>
<li>tcpdump shows RAs received from ISP<br /><pre>
21:04:22.040097 00:01:5c:7a:d0:46 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 198: fe80::201:5cff:fe7a:d046 > ff02::1: ICMP6, router advertisement, length 144
</pre></li>
<li>RA dest IPv6 multicast address appears to be correct, MAC address appears to be correct for IPv6 multicast</li>
<li>when running tcpdump, IPv6 default route is re-added to pfsense routing table</li>
</ul>
hypothesis:
<ul>
<li>tcpdump places cpsw0 interface is promiscuous mode, and when in promiscuous mode, RA's are received</li>
<li>when cpsw0 not in promiscuous mode, RA's are not received</li>
<li>works temporarily on release/renew possibly because IPv4 DHCP client places interface in promiscuous mode temporarily when acquiring lease</li>
</ul>
experiment 1:
<ul>
<li>"ifconfig cpsw0 promisc" </li>
<li>result: IPv6 default route is stable over several days</li>
</ul>
experiment 2:
<ul>
<li>"ifconfig cpsw0 -promisc; tcpdump -pni cpsw0" </li>
<li>-p flag prevents tcpdump from placing interface in promiscuous mode</li>
<li>result: ISP RAs are not seen</li>
</ul>
workaround:
<ul>
<li>use shellcmd pkg to run "ifconfig cpsw0 promisc" on startup</li>
</ul> pfSense - Bug #8419 (New): webgui, when menubar is fixed to the top of the screen, the last items...https://redmine.pfsense.org/issues/84192018-04-02T17:36:14ZPi Ba
<p>webgui, when menubar is fixed to the top of the screen, the last items of long menus cannot be seen/used.</p>
<p>fix: <a class="external" href="https://github.com/pfsense/pfsense/pull/3930">https://github.com/pfsense/pfsense/pull/3930</a></p> pfSense - Bug #6605 (Confirmed): rc.linkup logic issues with actions takenhttps://redmine.pfsense.org/issues/66052016-07-12T19:46:41ZChris Buechlercbuechler@gmail.com
<p>The actions taken by rc.linkup differ depending on whether the interface has a static or no IPv4 and IPv6 IP, and every other case (where either the v4 or v6 type of the interface is dynamic). <br /><a class="external" href="https://github.com/pfsense/pfsense/blob/RELENG_2_3/src/etc/rc.linkup#L70">https://github.com/pfsense/pfsense/blob/RELENG_2_3/src/etc/rc.linkup#L70</a></p>
<p>While there are no doubt some edge case reasons for that being the way it is, it's not sensible logic in general. The actions taken should be much closer to the same between them.</p>
<p>The only known problem this causes is with CARP. The interface_bring_down function removes CARP VIPs from the interface. If you have a static v4 and track6 LAN, this makes CARP get into dual master on WAN when the LAN loses link. What should happen is the CARP IP stays in INIT, which increments net.inet.carp.demotion by 240, which makes the secondary take over for the WAN VIPs. What actually happens is it increments demotion by 240, fails over to the secondary, then the VIP is deleted from the LAN on primary so demotion gets a +240 on the primary because the VIP is gone, and the primary takes back over master. Then you have dual master on WAN.</p>
<p>interface_bring_down should never be run on an interface where a CARP VIP resides to avoid this situation. It's questionable whether it's ever actually necessary or desirable when losing link on a NIC.</p>
<p>This is a potentially touchy area for regressions, so it'll need a good deal of review, testing and time to run in snapshots.</p> pfSense - Bug #6220 (Confirmed): state mismatch with host-initiated traffic matching binat to IP ...https://redmine.pfsense.org/issues/62202016-04-20T20:51:03ZChris Buechlercbuechler@gmail.com
<p>Replies to traffic initiated from the host itself, translated by binat, to a target IP that isn't locally assigned on the system, results in a state mismatch on reply traffic. Simplified (as much as possible) example.</p>
<p>OS setup: <br /><pre>
vtnet0 - 172.30.6.133/24 - acting as WAN
vtnet1 - 192.168.1.1/24 - acting as LAN
172.30.6.1 default gateway
172.30.6.88/32 routed to 172.30.6.133 by 6.1
</pre></p>
<p>pf.conf: <br /><pre>
binat on vtnet0 from 192.168.1.1 to any -> 172.30.6.88
pass out quick from any to any
block quick from any to any
</pre></p>
<p>Then generate some traffic that matches the binat. <br /><pre>
# ping -S 192.168.1.1 172.30.6.1
</pre></p>
<p>and you get no reply. Counters show the egress traffic matches the binat and 'pass out' rules, but the replies match the block rule.</p>
<pre>
# pfctl -vvsn
@0(0) binat on vtnet0 inet from 192.168.1.1 to any -> 172.30.6.88
[ Evaluations: 38 Packets: 6 Bytes: 504 States: 1 ]
[ Inserted: pid 20547 State Creations: 1 ]
# pfctl -vvsr
@0(0) pass out quick all flags S/SA keep state
[ Evaluations: 45 Packets: 32 Bytes: 2824 States: 4 ]
[ Inserted: pid 20547 State Creations: 6 ]
@1(0) block drop quick all
[ Evaluations: 39 Packets: 39 Bytes: 3609 States: 0 ]
[ Inserted: pid 20547 State Creations: 0 ]
</pre>
<p>The state that's created is correct. <br /><pre>
# pfctl -vvss | grep -A 2 icmp
vtnet0 icmp 172.30.6.88:51795 (192.168.1.1:51795) -> 172.30.6.1:51795 0:0
age 00:00:03, expires in 00:00:10, 4:4 pkts, 336:336 bytes, rule 0
id: 000000005717dd2c creatorid: 776a8091
</pre></p>
<p>If you change the ruleset to allow the reply traffic, you get the first ping response, but nothing subsequent because the ping reply state prevents it from matching the binat state, so subsequent echo requests go out without the binat's translation.</p>
<p>This pf.conf: <br /><pre>
binat on vtnet0 from 192.168.1.1 to any -> 172.30.6.88
pass out quick from any to any
pass in quick from any to any
</pre></p>
<p>With the same ping, you get one reply and nothing further. <br /><pre>
# ping -S 192.168.1.1 172.30.6.1
PING 172.30.6.1 (172.30.6.1) from 192.168.1.1: 56 data bytes
64 bytes from 172.30.6.1: icmp_seq=0 ttl=64 time=0.515 ms
</pre></p>
<pre>
# pfctl -vvss | grep -A 2 icmp
vtnet0 icmp 172.30.6.88:42562 (192.168.1.1:42562) -> 172.30.6.1:42562 0:0
age 00:00:14, expires in 00:00:00, 1:1 pkts, 84:84 bytes, rule 0
id: 010000005717dbe5 creatorid: 5cdfce54
--
vtnet0 icmp 192.168.1.1:42562 <- 172.30.6.1:42562 0:0
age 00:00:33, expires in 00:00:10, 1:32 pkts, 84:2688 bytes, rule 1
id: 000000005717de2f creatorid: 5cdfce54
</pre>
<p>The second state shouldn't be there, it should match the first.</p>
<a name="Workarounds"></a>
<h3 >Workarounds<a href="#Workarounds" class="wiki-anchor">¶</a></h3>
<p>Two ways I know of to make this not happen.</p>
<p>1) Add an IP alias for the translated IP.</p>
<pre>
# ifconfig lo0 inet 172.30.6.88/32 alias
</pre>
<p>It just needs to be defined on the system, doesn't have anything to do with ARP or anything. With the same configs above, it'll work after adding that alias to lo0.</p>
<p>2) Discovered by accident that adding a setkey "none" policy matching the translation IP also makes it work.</p>
<pre>
# setkey -DP
192.168.1.0/24[any] 192.168.1.0/24[any] any
in none
created: Apr 20 19:53:07 2016 lastused: Apr 20 20:46:13 2016
lifetime: 9223372036854775807(s) validtime: 0(s)
spid=12 seq=9 pid=23348
refcnt=1
</pre>
<p>I'm pretty sure the problem is in tryforward. It doesn't happen on any pre-2.3 versions.</p> pfSense - Bug #6026 (New): webinterface, firewall rules, wrapping of columns or visible (horizont...https://redmine.pfsense.org/issues/60262016-03-24T16:39:33ZPi Ba
<p>with some rulesets the 'action buttons' dont show on the screen, so first need to scroll down, then right, then back up again to delete, or move a rules using the anchors.. which isnt convenient when ruleset is several screens long..</p>
<p>Screenshot attached shows this happening on even the widest possible screen/layout..</p>
<p>The screenshot is made of specific testrules, but i first noticed in a production system where it happens to that action buttons are outside the visible area. And horizontal scroll-bar is at the bottom of the ruleset..</p> pfSense - Bug #5791 (Confirmed): tftp-proxy functionality is easilly broken by unrelated ruleshttps://redmine.pfsense.org/issues/57912016-01-21T17:30:55ZTed Lumpfsense.org@tedworld.com
<p>The anchors on which the tftp-proxy depends, are inserted at the end of the filter chain. Any conflicting rule entered in the chain prior to it - currently every rule is prior to it - will effectively disable tftp-proxy on that interface. A conflicting rule is one which matches the traffic which MUST reach tftp-proxy. For example, a final block-all rule which also is used as a block logging mechanism will disable the tftp-proxy, even though it would appear to be unrelated on the surface. Other rules which inadvertently match server responses will do the same thing.</p>
<p>See this post for more background: <a class="external" href="https://forum.pfsense.org/index.php?topic=48891.0">https://forum.pfsense.org/index.php?topic=48891.0</a></p>
<p>I would suggest a change to make the tftp-proxy less brittle in conjunction with user rules. Ultimately it would be great if the tftp-proxy anchor appeared in the list of rules, even if just as a grayed out placeholder, so that other rules could be arranged ahead or behind it, and so that it's presence could be clearly observed.</p>
<p>In it's current state it's impossible to know where it sits in the current order without a technical deep-dive, which leads to so many user problems thanks to it's non-obvious behavior and interactions, thus it would be a vast improvement to be able to visualize it within the same context as the rules which can easily break it. This might be easier than leaving it invisible and trying to devise program logic to deconflict every possible rule permutation. The user could see the anchor and would be responsible for manually deconflicting their rule chain... plus, I like the idea of not having invisible things lurking on my interfaces.</p> pfSense - Bug #5306 (New): textarea fields should have linebreaks sanitized automatically on savehttps://redmine.pfsense.org/issues/53062015-10-14T04:13:34ZKill Bill
<p>To avoid nonsense like this: <a class="external" href="https://github.com/doktornotor/pfsense-packages/blob/patch-2/config/squid3/34/squid.inc#L85">https://github.com/doktornotor/pfsense-packages/blob/patch-2/config/squid3/34/squid.inc#L85</a></p>