pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162024-02-29T06:58:23ZpfSense bugtracker
Redmine pfSense Packages - Bug #15296 (New): WAN Interface cannot added to ntopng if offline-packet loss https://redmine.pfsense.org/issues/152962024-02-29T06:58:23ZSergei Shablovsky
<p>Brilliant pfSense DevTeam !</p>
<p>In multi-WAN pfSense configuration WAN interfaces that pfSense decide in “Offline, Packet loss” state CANNOT BE ADDED into ntopng config.</p>
<p>(to adding certain WAN connection (for example if WAN interface come from “Offline, packet loss” state to “Online” state), ntopng need to be disabled, service stopped, ntopng pkg uninstalled (with all data and configs deleted), than hardware rebooting, install ntopng pkg again, and only after that new WAN with “Online” status becomes visible as Interface in ntopng”).</p>
<p>But LAN interfaces ALL would be ADDED as well even some of them are not connected physically. So this bug related only WAN interfaces.</p>
<p>P.S.<br />This is related for WAN DHCP, do not know about WAN STATIC.</p> pfSense - Bug #15083 (New): Installing to ZFS mirror does not format or populate EFI partition on...https://redmine.pfsense.org/issues/150832023-12-11T16:28:54ZJim Pingle
<p>Installing Plus 23.09.1 or CE 2.7.2 to a ZFS mirror does not format or populate the EFI partition on the additional disks of the mirror. Only the first disk in the mirror has a populated EFI filesystem with the expected loader files.</p>
<p>The EFI Partition for the second disk (or later) is created and labeled as <code>/dev/gpt/efiboot1</code> (and so on) but there is no filesystem on that partition (and thus, no files).</p>
<p>Should the first disk in the mirror fail, this would leave the system unbootable.</p>
<p>Can be worked around by manually creating and populating the additional EFI partition(s) post-install</p>
<p>For example, to format and populate the EFI filesystem on the second disk of the mirror:</p>
<pre><code class="shell syntaxhl"><span class="c"># newfs_msdos -F 32 -c 1 -L EFISYS1 /dev/gpt/efiboot1</span>
<span class="c"># mount_msdosfs /dev/gpt/efiboot1 /mnt</span>
<span class="c"># cp -R /boot/efi/ /mnt</span>
<span class="c"># umount /mnt</span>
</code></pre> pfSense Packages - Bug #15048 (New): Snort large memory consumption when updatinghttps://redmine.pfsense.org/issues/150482023-11-29T09:47:49ZRicardo ot
<p>Snort since the last updates uses a lot of memory when updating and it has a big impact. Can this be improved?</p>
<p>Thanks,</p>
<p>I have these configurations active for 2 interfaces:<br />Resolve Flowbits. checked.<br />Use IPS Policy. Checked.<br />IPS Policy Selection. Connectivity.<br />All the rulesets (Categories). Checked all</p>
<p>I already changed the PfBlokerng configuration to use "Unbound python mode" and changed the time so that the update is not done at the same time. This has improved PfblockerNg's memory usage.</p>
<p>System log Logs:</p>
<blockquote>
<p>Nov 29 00:48:16 php 46952 [pfBlockerNG] No changes to Firewall rules, skipping Filter Reload<br />Nov 29 00:45:00 php 46952 [pfBlockerNG] Starting cron process.<br />Nov 29 00:25:57 php 85398 [Snort] The Rules update has finished.<br />Nov 29 00:25:57 php 85398 [Snort] Snort has restarted on WANONT with your new set of rules...<br />Nov 29 00:25:45 php 85398 [Snort] Snort START for <abbr title="vmx3">WANONT</abbr>...<br />Nov 29 00:25:44 kernel pid 31736 (snort), jid 0, uid 0: exited on signal 11 (core dumped)<br />Nov 29 00:25:44 snort 31736 * * * Caught Term-Signal<br />Nov 29 00:25:43 php 85398 [Snort] Snort STOP for <abbr title="vmx3">WANONT</abbr>...<br />Nov 29 00:25:42 php 85398 [Snort] Building new sid-msg.map file for WANONT...<br />Nov 29 00:25:42 php 85398 [Snort] Enabling any flowbit-required rules for: WANONT...<br />Nov 29 00:25:42 php 85398 [Snort] Enabling any flowbit-required rules for: WANONT...<br />Nov 29 00:25:41 php 85398 [Snort] Updating rules configuration for: WANONT ...<br />Nov 29 00:25:41 php 85398 [Snort] Snort has restarted on LAN with your new set of rules...<br />Nov 29 00:25:29 kernel pid 29090 (snort), jid 0, uid 0: exited on signal 11 (core dumped)<br />Nov 29 00:25:29 php 85398 [Snort] Snort START for <abbr title="vmx1">LAN</abbr>...<br />Nov 29 00:25:28 snort 29090 *** Caught Term-Signal<br />Nov 29 00:25:27 php 85398 [Snort] Snort STOP for <abbr title="vmx1">LAN</abbr>...<br />Nov 29 00:25:27 php 85398 [Snort] Building new sid-msg.map file for LAN...<br />Nov 29 00:25:27 php 85398 [Snort] Enabling any flowbit-required rules for: LAN...<br />Nov 29 00:25:26 php 85398 [Snort] Enabling any flowbit-required rules for: LAN...<br />Nov 29 00:25:26 php 85398 [Snort] Updating rules configuration for: LAN ...<br />Nov 29 00:25:25 php 85398 [Snort] Building new sid-msg.map file for WAN...<br />Nov 29 00:25:25 php 85398 [Snort] Enabling any flowbit-required rules for: WAN...<br />Nov 29 00:25:25 php 85398 [Snort] Enabling any flowbit-required rules for: WAN...<br />Nov 29 00:25:24 php 85398 [Snort] Updating rules configuration for: WAN ...<br />Nov 29 00:25:24 php 85398 [Snort] Removed 49 obsoleted rules category files.<br />Nov 29 00:25:24 php 85398 [Snort] Hide Deprecated Rules is enabled. Removing obsoleted rules categories.<br />Nov 29 00:25:17 php 85398 [Snort] Feodo Tracker Botnet C2 IP rules were updated...<br />Nov 29 00:25:17 php 85398 [Snort] Feodo Tracker Botnet C2 IP rules file update downloaded successfully.<br />Nov 29 00:25:17 php 85398 [Snort] Emerging Threats Open rules file update downloaded successfully<br />Nov 29 00:25:15 php 85398 [Snort] There is a new set of Emerging Threats Open rules posted. Downloading emerging.rules.tar.gz...<br />Nov 29 00:25:15 php 85398 [Snort] Snort GPLv2 Community Rules file update downloaded successfully<br />Nov 29 00:25:13 php 85398 [Snort] There is a new set of Snort GPLv2 Community Rules posted. Downloading community-rules.tar.gz...<br />Nov 29 00:25:13 php 85398 [Snort] Snort Subscriber rules file update downloaded successfully<br />Nov 29 00:25:04 php 85398 [Snort] There is a new set of Snort Subscriber rules posted. Downloading snortrules-snapshot-29200.tar.gz...</p>
</blockquote> pfSense - Bug #15015 (New): Static routes not workinghttps://redmine.pfsense.org/issues/150152023-11-20T17:53:07ZSilviu Bajenaru
<p>Hello,</p>
<p>This morning I updated to PFSense 2.7.1 from 2.7.0. Now, I just tried to add a dynamic gateway and a static route. Unfortunately, the static route is not being added to the routing table. I restored the VM backup from this morning, before I updated, added the same gateway and static route and it was added to the routing table, and everything works fine.<br />I've set the priority to Urgent since this is quite bad for a router...?</p>
More info about my setup: I've got three sites, let's call them A, B and C. There is an IPSec tunnel between A and B, and one between B and C. Both tunnels are set with Mode VTI. I've assigned the ipsec interfaces and set the gateways and routes:<br />Site A has a gateway set on the IPSec interface and a route for site C that uses that gateway.<br />Site B has two gateways (one for each IPSec tunnel) and the following routes:
<ul>
<li>route to site A via the IPSec interface - gateway - going to site A</li>
<li>route to site B via the IPSec interface - gateway - going to site B<br />Site C has a gateway set on the IPSec interface and a route for site A that uses that gateway.<br />Site A was updated this morning to PFSense 2.7.1, while Site C is running 2.7.0.<br />Site A DOES NOT have the static routes added to the routing table.<br />Site C does have the static routes added to the routing table.</li>
</ul>
<p>Once I reverted Site A to 2.7.0, I did the same config again and the routes were added to the routing table.</p>
<p>Thank you.</p> pfSense - Bug #14906 (New): DHCPv4 server self-assigning address to own DHCP client-enabled inter...https://redmine.pfsense.org/issues/149062023-10-22T15:24:26ZLuca Piccirillo
<p>Assume three NICs: igc0, igc1, igc2<br />Assume a single bridge: bridge0 (OPT2, OPT3)<br />And a VLAN: igc0.1036</p>
<p>Interfaces assignment as follows:<br />WAN -> igc0.1036 -> IPv4 (DHCP): 1.2.3.4/30<br />LAN -> bridge0 -> IPv4 (static): 192.168.1.1/24<br />OPT1 -> igc0 -> IPv4 (static): 192.168.100.2/24<br />OPT2 -> igc1<br />OPT3 -> igc2</p>
<p>DHCP & RA enabled for LAN only.</p>
<p>The problem: switching OPT1 IPv4 settings from static to DHCP makes pfSense to assign itself an address from the LAN pool, also creating a wrong on-link route for its LAN subnet over the igc0 port, which is the underlying IF of WAN.</p>
<p>Of course this is easily noticeable when no other DHCP serve is active on that igc0 port broadcast domain.</p> pfSense - Bug #14891 (New): High CPU usage when interface get down and up due to proces check_rel...https://redmine.pfsense.org/issues/148912023-10-18T10:40:27ZThijs K
<p>Today I noticed that the cpu usage was high on my pfSense appliance (N5105, I226). <br />After looking in top I see that check_reload_status is fully taxing one core. <br />This process seems to be triggered when the wan interface comes down and up. <br />The process keeps running and taxing the CPU until it is manually stopped.</p> pfSense - Bug #14741 (New): PHP error in DNS Forwarder host overrides when the language is set to...https://redmine.pfsense.org/issues/147412023-09-02T10:26:29ZNicolas PISTER
<p>A PHP error occur when a user try to add or modify Host Override in DNS Forwarder module</p>
<pre>
amd64
14.0-CURRENT
FreeBSD 14.0-CURRENT #1 RELENG_2_7_0-n255866-686c8d3c1f0: Wed Jun 28 04:21:19 UTC 2023 root@freebsd:/var/jenkins/workspace/pfSense-CE-snapshots-2_7_0-main/obj/amd64/LwYAddCr/var/jenkins/workspace/pfSense-CE-snapshots-2_7_0-main/sources/FreeBSD-src-REL
Crash report details:
PHP Errors:
[02-Sep-2023 11:55:24 Europe/Paris] PHP Fatal error: Uncaught ValueError: Unknown format specifier "p" in /usr/local/www/classes/Form/Input.class.php:127
Stack trace:
#0 /usr/local/www/classes/Form/Input.class.php(127): sprintf('Nom de domaine ...', '<br />')
#1 /usr/local/www/services_dnsmasq_edit.php(85): Form_Input->setHelp('Domain of the h...', '<br />')
#2 {main}
thrown in /usr/local/www/classes/Form/Input.class.php on line 127
[02-Sep-2023 11:58:37 Europe/Paris] PHP Fatal error: Uncaught ValueError: Unknown format specifier "p" in /usr/local/www/classes/Form/Input.class.php:127
Stack trace:
#0 /usr/local/www/classes/Form/Input.class.php(127): sprintf('Nom de domaine ...', '<br />')
#1 /usr/local/www/services_dnsmasq_edit.php(85): Form_Input->setHelp('Domain of the h...', '<br />')
#2 {main}
thrown in /usr/local/www/classes/Form/Input.class.php on line 127
[02-Sep-2023 11:58:46 Europe/Paris] PHP Fatal error: Uncaught ValueError: Unknown format specifier "p" in /usr/local/www/classes/Form/Input.class.php:127
Stack trace:
#0 /usr/local/www/classes/Form/Input.class.php(127): sprintf('Nom de domaine ...', '<br />')
#1 /usr/local/www/services_dnsmasq_edit.php(85): Form_Input->setHelp('Domain of the h...', '<br />')
#2 {main}
thrown in /usr/local/www/classes/Form/Input.class.php on line 127
</pre>
<p>I think it come from a french translation file because when i use original language, everithing works.</p> pfSense - Bug #14734 (New): Alias FQDN resolving issue results in incomplete tableshttps://redmine.pfsense.org/issues/147342023-08-31T13:59:20ZRobert Gijsen
<p>In CE 2.7.0, there are still issues when FQDN are used in aliasses. Vonsider an alias with 3 entries, 2 static IP's and one FQDN, pointing to one of those IP's as well. When the FQDN changes to the other IP, the IP it had initially is gone from the table.</p>
<p>Steps to reproduce:</p>
Create an alias
<ul>
<li>add 1.1.1.1</li>
<li>add 8.8.8.8</li>
<li>add a (public) dns entry you created, pointing to 1.1.1.1, ie pfsensetest.domain.com</li>
<li>monitor the table-entry for the alias, all will be ok</li>
<li>now change the DNS entry for pfsensetest.domain.com from 1.1.1.1 to 8.8.8.8 and wait for it to be replicated and pfSense to pick it up</li>
<li>in my setups, 1.1.1.1 got deleted from the table. So while 8.8.8.8 is in there 'twice' now, and 1.1.1.1 only once statically, it's not there anymore</li>
<li>killing filterdns and reloading filters repopulates the tables correctly it seems.</li>
</ul>
<p>It looks like when the FQDN is resolved, it overrules the static entry if one with the same value exists, and when the FQDN changes, the static entry is not put back in to the table. I tailed resolver.log while reproducing the issue, but it made no notion at all of resolving the FQDN to another IP. So I don't know what log to add, or which log to enable verbose logging for.</p>
<p>I consider this high priority, as it has high potential of actually functionally breaking an environment.</p> pfSense - Bug #14604 (New): Bugs in dhclient implementation according to RFC 2131https://redmine.pfsense.org/issues/146042023-07-23T14:11:19ZNazar Mokrynskyi
<p>I had issues with one of the ISPs on pfSense and after talking to their tech support and observing what is happening I believe there are bugs in dhclient used by pfSense.<br />It is likely an upstream issue, but I don't use FreeBSD, so I report it here.<br />This is what triggers <a class="external" href="https://redmine.pfsense.org/issues/14237">https://redmine.pfsense.org/issues/14237</a> (which I believe is a buggy gateway groups implementation in pfSense and is a distinct issue, this one is just one way to trigger it, but maybe not the only one).</p>
<p>Dump of communication between pfSense and DHCP server of ISP is also attached.<br />The issue happened on 2.6.x and still happens on 2.7.0 that I'm currently running.</p>
<p>Below is basically an English translation of the response from IPS support representative.</p>
<p>The first thing that is believed to be handling DHCPDISCOVER. According to RFC 2131:<br /> The client begins in INIT state and forms a DHCPDISCOVER message.<br /> The client SHOULD wait a random time between one and ten seconds to<br /> desynchronize the use of DHCP at startup.</p>
<p>So client must wait for DHCPOFFER up to 10 seconds. During this time client can receive answers from multiple DHCP servers and pick settings it prefers.</p>
<p>The other issue is that according to RFC 2131 Unicast request Request Renew must be done between T1 and T2. Time approximately equal tothe lease time<br />(with slight random offset) - T1 timer. pfSense's dhclient only uses T2 (0.85*lease time), this is not quite correct, request according to T2 timer is usually<br />done in case first request to extend lease failed (depends on implementation and DHCP client settings). According to RFC after T2 time client must switch to<br />REBINDING and make boardcast request, which is what happened. If cient doesn't send request/doesn't receive response within lease time then settings must be<br />cleared and procedure of obtaining IP address start over.<br />Current lease time is 10 minutes (600 seconds).<br />Separately sometimes dhclient doesn't send DHCPREQUEST within lease time, for instance record <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Todo: PPTP users integration with user manager (Closed)" href="https://redmine.pfsense.org/issues/34">#34</a> and 37, between then there was more than 600 seconds and<br />procedure to get IP address started over, which is when Internet access was temporarily lost.</p> pfSense Packages - Bug #14510 (New): match rpki invalid What is actually executed is match rpki v...https://redmine.pfsense.org/issues/145102023-06-26T22:03:58Zyon Liuinfo@ipv6china.com
<p>when i setup match rpki invalid for deny, then actually executed is match rpki valid for deny.</p>
<p>please your check and fix it.</p> pfSense - Bug #14434 (New): PPPoE WAN interface with VIPs causes continuous interface restartinghttps://redmine.pfsense.org/issues/144342023-05-30T13:55:03ZBert Smith
<p>I have a /28 routable legacy IP block from the ISP, and they assign the first usable address of the /28 block as a /32 to the PPPOE interface, so i have:</p>
<p>Routable block: x.x.x.64/28<br />PPPOE address: x.x.x.65/32<br />LAN address CARP VIP: x.x.x.65/28</p>
<p>This configuration worked fine in 22.05, but is broken in 23.01 and remains broken in 23.05.</p>
<p>The PPPOE connection establishes and calls /etc/rc.newwanip, which then calls find_interface_ip() and get_interface_ip() to determine the address assigned to pppoe0. These functions return NULL, which causes rc.newwanip to restart the pppoe0 interface. This then causes an endless loop. The logs show the correct interface name, but no IP:</p>
<pre>
rc.newwanip: on (IP address: ) (interface: WAND[opt5]) (real interface: pppoe0).
</pre>
<p>Looking through the find_interface_ip() function, i can see it looks for $interface_ip_arr_cache - this array exists, but is empty causing the function to fail and return NULL.</p>
<p>I can see that if $interface_ip_arr_cache does not exist, it should open /var/db/${interface}_ip</p>
<pre>
if (!isset($interface_ip_arr_cache[$interface]) or $flush) {
if (file_exists("/var/db/${interface}_ip")) {
</pre>
<p>The file /var/db/pppoe0_ip is present and contains the correct address.</p>
<p>I'm hoping someone more familiar with the codebase and changes between 22.05/23.01 could give some insight into this otherwise i'll be trying to track it down further.</p> pfSense - Bug #14397 (New): DHCPv4 client (dhclient) does not use 802.1p Priority tagging on DHCP...https://redmine.pfsense.org/issues/143972023-05-19T14:52:52ZTue Madsen
<p>Some ISPs using VLANs for service, require DHCPv4/v6 Frames to be 802.1p priority tagged. <br />pfSense has the option to do this by either:<br />- Setting VLAN priority tagging in the Interface DHCP options (if you are not using Advanced configuration or a predefined configuration file)<br />- If using advanced configuration: By adding “vlan-pcp x” in the advanced modifier options.</p>
<p>BUG:<br />This priority setting in only used in DISCOVER and RELEASE frames sent by dhclient - NOT in RENEW or REBIND.</p>
<p>This is now causing major problems in France where Orange (Major ISP) has upgraded to also requiring the RENEW frames to be properly VLAN Priority tagged.<br />This causes the uplink to stop working when a renew is due. (About once a day)</p>
<p>I don’t know if the issue is the same in DHCPv6</p>
<p>The issue was patched in OPNsense about a month ago, and they decided to drop the advanced options overwrite of the VLAN priority setting in interface DHCP options. <br />Instead they let the user choose if VLAN priority should be used via the interface DHCP VLAN Priority setting already available. <br />If selected it would - apart from adding “vlan-pcp x” to the dhclient config - also set the priority tag in the builtin pffilter rule that passes Interface DHCP client traffic. This adds the tag to RENEW and REBIND frames.</p>
<p>The issue occurs because dhclient uses a bfg interface for DISCOVER and RELEASE - thus respecting the vlan-pcp settings. But for RENEW it uses a simple socket, and that causes it not to be tagged correctly. In pfSense you cannot create a floating match rule to manually tag the traffic that has higher priority than the builtin pass quick rule for the interface DHCP client.</p> pfSense Packages - Bug #14390 (New): Squid: SECURITY ALERT: Host header forgery detectedhttps://redmine.pfsense.org/issues/143902023-05-16T09:19:15ZSimon Byrnand
<p>In Squid version 3.2 in 2012 a "fix" for a potential security vulnerability involving host header forgery was added, this is described briefly here:</p>
<p><a class="external" href="https://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery">https://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery</a></p>
<p>It is also mentioned in the documentation for the host_verify_strict squid option below, which references CVE-2009-0801:</p>
<p><a class="external" href="http://www.squid-cache.org/Doc/config/host_verify_strict/">http://www.squid-cache.org/Doc/config/host_verify_strict/</a></p>
<p>In essence, when transparent interception is used Squid will obtain the SNI for https or host header for http, do a DNS lookup on this hostname enumerating the IP addresses returned, then double check the destination IP address of the intercepted packet is one of those returned from the DNS request.</p>
<p>If it's not, the request fails and returns an HTTP/409 error to the client, which shows up as a "NONE/409" in the squid access.log.</p>
<p>While this extra check is well intentioned, probably seemed like the right thing to do in 2012 and no doubt does address CVE-2009-0801, today in 2023 it has massive collateral damage and makes transparent proxying almost unusable for many large services that use CDN's, as it causes frequent but intermittent connection failures for many CDN based services.</p>
<p>The issue here is one of DNS coherency. As I've discovered when looking into this in detail in the last week CDN service DNS records have <ins>extremely</ins> short TTL times of around 10 or 20 seconds typically. After that TTL expires you will more often than not get a completely disjoint set of different IP addresses returned than what you got just 20-30 seconds earlier.</p>
<p>A couple of examples I'm working with which can be queried multiple times over a couple of minutes with dig returning different results are:</p>
<p>res.cdn.office.net<br />uk.ng.msg.teams.microsoft.com</p>
<p>These are both used by Office 365 / Microsoft Teams, however this issue of very short TTL times and disjointed IP address response sets seems to be pervasive in large CDN infrastructure as of 2023.</p>
<p>The end result is intermittent http/https query failures returning HTTP/409. In my testing in the last few days Microsoft Teams on iOS is very susceptible to this problem and is basically unusable as it will work for a while then just fail to connect to the servers or be able to start a video call due to Squid returning HTTP/409 errors to it.</p>
<p>Ensuring DNS coherency between clients and proxy server (by forcing clients and proxy server to use the same DNS server - which I already do) does help on regular websites with long TTL's, or websites whose IP address result set is consistent, and is essential to getting transparent proxying working, however it does <ins>not</ins> help this issue with CDN's. :(</p>
<p>Here is what I think is happening in the specific instance of the Teams client, however the same basic scenario can apply to other client software as well.</p>
<p>The Teams app performs a DNS lookup on uk.ng.msg.teams.microsoft.com and gets multiple IP addresses returned. It chooses one and makes an https query to the server using this IP address. Squid intercepts this transparently, reads the SNI, does its own DNS lookup from the same DNS server, gets the same response, verifies that the IP address of the destination packets match the DNS records and everything works fine.</p>
<p>A couple of minutes later Teams makes a new https request to the same hostname <ins>using an internally cached (within the application) copy of the IP address</ins> - Squid performs another DNS lookup on the hostname as the extremely short TTL has already expired, however this time the IP addresses returned are completely different so the request fails with an HTTP/409 error. This breaks the client.</p>
<p>TTL on DNS records only mandates how long a DNS server or OS level resolver can cache the result for, it <ins>cannot</ins> prevent an application choosing to continue to use the same IP address for longer than the TTL. It would be perfectly reasonable for an HTTPS connection to stay open for an hour for example even if the DNS record has a TTL of 10 seconds. Absent the transparent proxy there is no issue because the server IP's remain valid for long periods of time (probably days/weeks) even though the DNS records are constantly rotating every 10-60 seconds or so.</p>
<p>From my perspective, the transparent mode is mostly useless now due to the combination of this original 2012 patch (which to be fair is a Squid patch not anything specific to PFSense) and the ubiquitous use of CDN's with extremely low DNS record TTL's and disjoint result sets that are constantly cycling IP addresses in and out of the results.</p>
<p>This issue has been discussed in the PFSense forum before:</p>
<p><a class="external" href="https://forum.netgate.com/topic/159364/squid-squidguard-none-409-and-dns-issue">https://forum.netgate.com/topic/159364/squid-squidguard-none-409-and-dns-issue</a></p>
<p>However the only outcomes were workarounds such as explicit client proxy settings or use of WPAD, both of which only admit that transparent proxying is broken. I make use of both of these where possible but there are still many cases where this is not possible.</p>
<p>The only true solution to get transparent mode working reliably again seems to be to walk back the "fix" applied back in Squid 3.2 and accept that theoretical exploit could be used, however without doing so we basically have to give up on transparent proxying altogether.</p>
<p>Patching this out has been discussed in a couple of places that I've found, here is one:</p>
<p><a class="external" href="https://github.com/NethServer/dev/issues/5348">https://github.com/NethServer/dev/issues/5348</a></p>
<p>To reproduce and monitor this issue is fairly easy:</p>
<p>Set up Squid in PFSense with transparent proxying enabled. Enable additional debug logging by adding <ins>debug_options ALL,1 rotate=7</ins> to Advanced Features -> Custom Options (Before Auth) then try using apps such as Microsoft Office apps that make heavy use of CDN's, making sure that the client has no proxy setting.</p>
<p>In /var/squid/logs/cache.log if the problem occurs you will see entries like:</p>
<p><code><br />2023/05/16 10:16:08 kid1| SECURITY ALERT: Host header forgery detected on local=3.227.250.226:443 remote=10.2.132.38:50635 FD 526 flags=33 (local IP does not match any domain IP)<br />2023/05/16 10:16:08 kid1| SECURITY ALERT: on URL: kinesis.us-east-1.amazonaws.com:443<br />2023/05/16 10:16:08 kid1| SECURITY ALERT: Host header forgery detected on local=3.227.250.226:443 remote=10.2.132.38:50636 FD 526 flags=33 (local IP does not match any domain IP)<br />2023/05/16 10:16:08 kid1| SECURITY ALERT: on URL: kinesis.us-east-1.amazonaws.com:443<br />2023/05/16 10:16:09 kid1| SECURITY ALERT: Host header forgery detected on local=17.253.29.208:443 remote=10.2.133.96:62179 FD 526 flags=33 (local IP does not match any domain IP)<br />2023/05/16 10:16:09 kid1| SECURITY ALERT: on URL: app-site-association.cdn-apple.com:443<br />2023/05/16 10:16:09 kid1| SECURITY ALERT: Host header forgery detected on local=3.227.250.226:443 remote=10.2.132.38:50637 FD 526 flags=33 (local IP does not match any domain IP)<br />2023/05/16 10:16:09 kid1| SECURITY ALERT: on URL: kinesis.us-east-1.amazonaws.com:443<br /></code></p>
<p>These log entries show both the host name that was requested by the client and the "local" IP address that the client was trying to connect to, if you do multiple DNS lookups of the hostname over a couple of minutes you will find that sometimes it returns the IP address, sometimes it does not.</p>
<p>While I appreciate this issue is an upstream issue I think it very unlikely that the Squid maintainers would accept a patch to walk back the change that was made in 2012, however I would argue that the transparent mode is barely usable due to this issue, so hopefully you would consider a patch to address this.</p>
<p>Regards,<br />Simon</p> pfSense Packages - Bug #13544 (New): SquidGuard either denying everything or proxying everythinghttps://redmine.pfsense.org/issues/135442022-10-05T01:40:03ZJimmy Michaelson
<p>Hey,</p>
<p>I truly doubt this is a configuration issue as I've tried all the possible combinations.</p>
<p>Relevant images and config:</p>
<p><a class="external" href="https://forum.netgate.com/topic/175057/10-btc-bounty-squid-proxy-whitelist-per-source-ip/6">https://forum.netgate.com/topic/175057/10-btc-bounty-squid-proxy-whitelist-per-source-ip/6</a></p>
<p>FYI: The bounty has been bumped to $20 and is also valid here.</p> pfSense - Bug #9295 (New): IPv6 PD does not work with PPPOE (Server & Client)https://redmine.pfsense.org/issues/92952019-01-29T11:51:01ZDirk Steingäßer
<p>Hi,</p>
<p>as encountering DHCPv6 with Prefix delegation does not work together with PPPOE Server vice versa it is not possible to get a prefix with an interface where the IPv4 Uplink is PPPOE.</p>