@jimp said in pimd 0.0.2 package defects/anomalies:

What specific interfaces does PIMD fail on for you? I am not aware of any issues with realtek (reX) but I could see issues with some virtual types.

I took the time to dig in on this, because I've been forever a bit confused on just what interfaces I even need to define :)

BACKGROUND
0) I do and did have Default Bind set to Bind to None. As you'll see, it doesn't necessarily help (and I may have found at least part of the bug ;) )

I have two HW ifc's, re0 (LAN - VLAN trunked) and re1 (WAN, via pppoe, specified as VLAN 201 by the ISP) Thus, for my WAN there are three levels of interface: re1 (raw hardware) re1.201 (VLAN tagged) pppoe0 (PPP interface) For my LAN there's two levels: raw re0 and the re0.NN VLAN's. I also have OpenVPN (ovpns1)

OBSERVATIONS

A) At the time of the above report:

I had interfaces defined for re0, re1.201, and ovpns1 (I didn't define one for re1) On startup, PIMD always reads vif's from the kernel, and tries to bring them up. (this WITH Default Bind of None.) pimd was seeing, and failing for: re1, ovpns1, and re1.201 ("Invalid phyint address")

B) Outside of pimd, having vif's re0 and re1.201 defined has not caused issues elsewhere in pfsense. I've now removed them and pimd no longer tries to bring up re1 or re1.201.

C) Even with the above cleaned up... if I try to bring up interface ovpns1 (Bind Always Enable), pimd says it is an invalid interface. (FWIW, pimd does not see ovpns1 when it brings up the kernel-defined list of interfaces.)

Presumably, this means pimd can't handle going across openvpn. Any idea how to enable this? (I used to do that all the time with multicast scanning... it would VERY much help to get this working!)

D) As reported already, but with more specificity:

Not sure why but pimd is defining a "Local static RP: 169.254.0.1, group 232.0.0.0/8" For a while, every N seconds (16?) pimd reports "route to: 169.254.0.1 destination is: 0.0.0.0 gateway is: (my ISP gateway!)" then spits out an error:
"For src 169.254.0.1, iif is <WAN iif>, next hoprouter is ...: NOT A PIM ROUTER" AND in the log shows this as a Candidate RP: (69.254.0.1, incoming 9, pref 232/8, prio 1, holdtime 65535) A while later, that entry disappears. But the error logs are there anyway for my pleasure ;) Any idea how to configure so 169.254.0.1 is never defined as an RP?

That just seems el-wrongo :(

E) Not sure what is causing the following. Doesn't seem to cause harm yet it is anomalous so I'm mentioning it: :)

After working through the kernel vifs, and the pimd.conf config... And JUST before first listing the Virtual Ifce Table in the log... pimd is adding one more vif of its own:
Vif (n+1), Local address: same as Vif 0, Subnet: "register_vif0", Thresh: 1, Flags: (blank) That vif just sits there... I don't find any docs on register_vif0. Do you know?

THANK YOU for getting this into pfSense!!!
p

@DefectiveRobot these changes are merged to the latest version of squid pkg: https://redmine.pfsense.org/issues/10450

can you test it?

584c8a5f-8466-42f5-afbe-4be601b72f7a-image.png

I would get it working before enabling things like this too. You really have to know what you are doing to get all of that right.

@jimp thanks.. that did it

@anandpeculiar
It might be enough to restart the pfSense's syslog service, so that it can re-create the log unix-socket also inside the haproxy chroot directory.?.

Native FreeBSD 11.3 packages don't know nothing about pfSense. So how could they support it ?

pfSense packages can be based on packages build for FreeBSD 11.3, and have then added to them the GUI part , and more code to use the right places.
pfSense uses FreeBSD "with modifications".

@RahulGarg said in CLI installed pfsense packages not showing up in GUI:

I used the command "pkg install squid-4.9" and the installation was successful.

then you should continue using the official FreeBSD command interface : the console or SSH access.
But be ware : you didn't install it on a native FreeBSD 11.3, but on pfSense, based on FreeBSD - there is a difference.

new version from pf2ad is working :)

@zacha fixed in squid 0.4.44_15

@C0RR0SIVE said in Squid proxy NONE/503:

I just use Shallalist for my SquidGuard, it helps block some common annoyances really, don't think it has been updated in some time though. More useful if you have kids trying to get to porn sites more than anything IMO.

Yeah, I use Unifi AP's and a Captive Portal in my Unifi software that requests they setup the proxy on their device using a proxy.pac file that's stored on a local webserver. When they pull from that file they go through HTTP/S just fine. If they don't they just get rejected on 443/80. Haven't had an issue with guests doing that so far. I also make sure I link to instructions stored on the local web server so they can follow those.

I have done some testing, but nothing concrete yet... I was on 2.4.5, and have been having some other issues with it. I decided to compile a version of 2.4.4-p3 and installed that, then restored all my settings. So far SQUID + SquidGuard has been rather stable and fast. I suspect the issue isn't just SQUID, but 2.4.5. Can you confirm what version of PFSense you are on?

I still see 503 errors, but those look purely SquidGuard and PFBlocker related (as in, what I am seeing, the URL is in my SquidGuard list or tied to a list on PFBlocker).

I see. I use Unifi AP's/controller too so we pretty have a similar setup. I have to play around with Squidguard when this issue gets fixed.

I'm also at pfsense 2.4.5 but I'm not sure when those 503 errors started showing up but I also highly suspect it's after the 2.4.5 upgrade.

@Smoothrunnings
I still don't understand the problem. Haproxy needs a IP to listen on.. Do you still have the old SmoothWall box? Can you check what the contents of haproxy.cfg was there? And besides that, if it warns i'm pretty sure there is actually something configured wrongly.. Perhaps can you share the current haproxy.cfg file? (its okay to partially obfuscate public ip's and domainnames you have in there as long as its done consistently..)

Please update to 0.4.44_21

@custardduck22
Common 'issue' like this is also the port :80 redirect that pfSense has, if for some reason a 'http' request is done instead of 'https' the pfSense webgui-redirect could get cached by a browser.. (that redirect it can be disabled in 'system/advanced settings') Anyhow good you've already got it fixed.

@guez I also specify that I use the transparent mode. If the solution is to configure a proxy by DHCP, that does not concern me and thank you to indicate it to me

Upgraded to pfSense 2.4.5 and this broke. I figured out the problem and it is very simple.

Delete old stuff:

pkg remove p5-XML-NamespaceSupport-1.12 pkg remove p5-XML-SAX-Base-1.09 pkg remove p5-XML-SAX-1.00 pkg remove p5-XML-LibXML-2.0132,1

Install the new packages:

pkg add https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/p5-XML-NamespaceSupport-1.12.txz pkg add https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/p5-XML-SAX-Base-1.09.txz pkg add https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/p5-XML-SAX-1.02.txz pkg add https://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/p5-XML-LibXML-2.0202,1.txz

For 2.5.0:

pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/latest/All/p5-XML-NamespaceSupport-1.12.txz pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/latest/All/p5-XML-SAX-Base-1.09.txz pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/latest/All/p5-XML-SAX-1.02.txz pkg add https://pkg.freebsd.org/FreeBSD:12:amd64/latest/All/p5-XML-LibXML-2.0202,1.txz

But the most important thing!!!
Open this file in a text editor:

/usr/local/libexec/squid/https-everywhere/squid.pl

Change to first line from:

#!/usr/local/bin/perl5

To:

#!/usr/local/bin/perl

And another thing that isn't necessary but I found helpful with heavy use is increasing the helpers:

Go to Services > Squid Proxy Server
Show advanced options at the bottom

And update in Custom Options (Before Auth):

url_rewrite_children 16