A criticism about PFSense Core Team behavior
-
Hi!
I know the title sound like a rant, but it is a criticism, I hope a constructive one.
I have been following all the mess with Squid usage since PFSense 2.1 got to Release Candidate. Two major problems have been reported:
1 - High Latency and service breakdown using Squid in environments with IPv4 only.
2 - Squid only uses the default gateway, even if there is a load balance and interface group.I see lots of threads about this going on and on, no one seems to fix it.
My criticism is about how this is being managed. The core team have no obligation to fix this asap, but the way things are going, it just stuck.
The problem #1 seems fixed using the Squid3-Dev(not stable) in PFSense 2.1.1, but the Squid Package maintained by the core team is not even compatible with IPv6 environments yet.
Problem #2 is a bit more extensive and complicated. When this was reported for the first time, I saw a lot of skepticism, no one was believing it, until tons of people started also reporting the same issue.
This thread talk about it: https://forum.pfsense.org/index.php?topic=66822.0
I also found other threads:
https://forum.pfsense.org/index.php?topic=75108.0
https://forum.pfsense.org/index.php?topic=74462.0
https://forum.pfsense.org/index.php?topic=74618.0I even found a Bug post on Redmine:
https://redmine.pfsense.org/issues/2854Jimp changed the priority to low, I mean, with all this being reported?
I don't know how they decide which feature is more needed than others, but there is a lot of people asking for this, not only in the English forum, take a look on the others.
Is this a paid only feature? How can we solve this? Is there any plan to address these problems?
I was all up to pay the subscription until PFSense 2.1 got all this mess with Squid.
-
point 2 is not new. point 2 has been like that for ever. It is an OS limitation that can't be cicumvented at this time.
-
point 2 is not new. point 2 has been like that for ever. It is an OS limitation that can't be cicumvented at this time.
Hello!
I think you misunderstood the problem.
This is not a limitation related to the FreeBSD used in PFSense, neither with the client OS(Windows/Linux/etc).
Example:
You have a Server running PFSense 2.1.2, with two ISP connections, both working well. You setup a Routing Group, define monitoring parameters, all the stuff to make the two gateways provide Internet connection two your internal clients. It will work really well… you'll see both ISP being used.Now install Squid. It will not recognize the Routing Group, always using the Default Gateway, no matter what Tier or routing priority you have set up. This is a Routing problem and/or a package limitation on Squid.
The thing is, this happens with Squid 2.7, one of the packages maintained by the core team. Squid 2.7 doesn't even work with IPv6 in some cases.There are other UTM solutions that use Squid and support this type of scenario, BrazilFW for an example.
However, my issue is with their behavior toward this. There is a growing tension between the Core Team and the community, because they reject everything that's not under their taste, accusing some packages to be the source of problems, when one of their own packages also cause problems, in a large scale.
-
i didn't misunderstand. ALL packages/services running on pfSense have problems loadbalancing on multi-wan. AFAIK this is because freebsd has limited (read unstable) support for multiple default routes.
linux (where brazilFW is based upon) , does not have this limitation.the good news is that freebsd 10 has much potential to fix these limitations. I expect that the core-devs will attempt to fix these things in upcomming releases starting from pfSense 2.3
-
i didn't misunderstand. ALL packages/services running on pfSense have problems loadbalancing on multi-wan. AFAIK this is because freebsd has limited (read unstable) support for multiple default routes.
linux (where brazilFW is based upon) , does not have this limitation.the good news is that freebsd 10 has much potential to fix these limitations. I expect that the core-devs will attempt to fix these things in upcomming releases starting from pfSense 2.3
Again, PFSense works fine with LB FO without Squid, so there is no limitation affecting the routing capabilities, not caused by the OS. The problem is between Squid and PFSense.
-
not exactly the same thing.
LB FO as you describe it, is dealt with by differently. loadbalancing works only works on pfSense when the service is not running on pfsense itself. (on a lan-client, a dedidcated squidbox, a dedicated dns server, …).
loadbalancing does not work with services/software running on the firewall itself, because policy routing can not easily be applied to them.
For example: Squid binds to a specific interface (generally the default gateway-interface). Policy routing can not be applied because, it can only happen when traffic goes from INTERFACE-A --> INTERFACE-group ; in squids case traffic does not go from A-->group: it goes straight out the WAN without any possibility of applying policy routing.There are some unreliable hacks possible with binding squid to localhost, forcing it through a gateway group by using quick floating rules ; even marking/matching packets to avoid some other oddness.
( This with lots of help from jimp,cmb & ermal when i did extensive testing of this on the 2.0-Beta till 2.0.3 builds)
I've all done that before and got it sort of working …. unreliably with annoyed customers as a result. My advice: for the moment best stick to failover-only when dealing with squid (see allow gateway switching)jeroen
-
not exactly the same thing.
LB FO as you describe it, is dealt with by differently. loadbalancing works only works on pfSense when the service is not running on pfsense itself. (on a lan-client, a dedidcated squidbox, a dedicated dns server, …).
loadbalancing does not work with services/software running on the firewall itself, because policy routing can not easily be applied to them.
For example: Squid binds to a specific interface (generally the default gateway-interface). Policy routing can not be applied because, it can only happen when traffic goes from INTERFACE-A --> INTERFACE-group ; in squids case traffic does not go from A-->group: it goes straight out the WAN without any possibility of applying policy routing.There are some unreliable hacks possible with binding squid to localhost, forcing it through a gateway group by using quick floating rules ; even marking/matching packets to avoid some other oddness.
( This with lots of help from jimp,cmb & ermal when i did extensive testing of this on the 2.0-Beta till 2.0.3 builds)
I've all done that before and got it sort of working …. unreliably with annoyed customers as a result. My advice: for the moment best stick to failover-only when dealing with squid (see allow gateway switching)jeroen
You do realize that the problem is with Squid Package, nothing to do with FreeBSD or PFSense itself, right?
The use of Float Rules with grouping worked really well up to version 2.0.3, Squid, Squid-guard, everything fine, now with version 2.1.x is a pain in the a…