I've also had a system where DNS resolving in LightSquid on pfSense 2.3.2 wasn't working correctly. Static leases and some (!) dynamic ones would display as host names, but all other hosts would display as IP adresses. Also, the same hosts that would display as IP adresses couldn't be resolved from the pfSense shell (!).

The solution was, coming from mostly default settings, to set "System Domain Local Zone Type" to "Static" and "DNS Query Forwarding" to "Enabled" in the DNS Resolver general settings, and to Click the "Refresh Full" button on the LightSquid settings page. To be frank, I'm not quite sure what these settings do "behind the curtains" - I've researched the meaning of these settings some time ago, but can't remember exactly what they do (yes, I'm old (; ). Could be that setting "System Domain Local Zone Type" to "Static" is sufficient to make it work.

Interestingly, clicking "Refresh Full" changed IP adresses to host names only in the "current day" report pages, not in the older reports (contrary to what the pfSense GUI says). I've been trying to get LightSquid to rebuild older reports by running "lightparser.pl" manually in the pfSense shell, but could't get LightSquid to rebuild older reports. I don't have the time to look deeper into this, maybe someone else could test and report back. I suspect there's a bug either in the way pfSense calls "lightparser.pl", or in the Perl script itself.

Also, there seems to be a flaw in the way LightSquid is called in pfSense. I've set the "report generation interval" to 1h, and the last report of every day always has a time of "23:00" (hours). I think this means that, for every given day, the report is missing all data from 23:00 - 23:59 hours, as the next run is logically "the next day" (= after 24:00 or 0:00 hours, even if only a few seconds). I'm not 100 % positive on that, though.

EDIT: I did some more digging, and it seems the "days before today"-stuff is connected to Squid log rotation. The GUI says "Defines how many days of logfiles will be kept. Rotation is disabled if left empty.". I assumed this means that the logs would rotate after the number of days I put in that field, but that assumption isn't correct. In fact, when entering any number in this field, the logs will be rotated every day, and logs with a higher "rotation sequence number" (appended to the log file name, like "access.log.x") will be deleted during log rotation. The number put into the GUI field is the number of logs that will be kept, not the number of days per se (it's only the number of days because pfSense "silently" rotates every 24 h). I think there should be two fields: "number of logfiles to keep" and "number of days to rotate the logfile after". The second field would have to change the "log rotate" cron entry in pfSense.

Sorry for getting a little off topic. I'll watch this thread for any replies, and maybe open a new thread with all that "rotating stuff" if there's any interest in the matter.

Hi,

There are a few ways to do that..

https://gist.github.com/PiBa-NL/d826e0d6b35bbe4a5fc3#file-haproxy-sending-the-source-ip-to-the-webserver

Options 1 and 3 are available in the webgui as a 'checkbox'.
Option 2 can be set as textual in advanced option.

Ill add that to my wiki shortly..

Regards,
PiBa-NL

Edit:
Added to wiki: https://github.com/PiBa-NL/pfsense-haproxy-package-doc/wiki/haproxy_pass_clientip_to_webserver

I face the same problem.

If I configure Firefox to use proxy, the web filtering works fine. but the transparent proxy doesn't work alone (without proxy setup in Firefox)

Hello,

It is not clear what you mean when you say "block in https". There are several possibilities:

terminate HTTPS connections so that browser warns the user "cannot establish connection" - yes it is possible allow HTTPS connection and show the 'this site is blocked' message to the user - you would need the SSL man in the middle allow HTTPS connections, decrypt it and block within site contents if something inappropriate found - you would need the SSL man in the middle and ICAP server like http://docs.diladele.com/tutorials/filtering_https_traffic_squid_pfsense/index.html

Best regards,
Sich

Solved this problem a few minutes ago for my installation.
In my setup i have Pfsense 2.3.2, squid and squidguard.

The problem i've dealth with, was the certification error "http". After clicking everything possible in squid configuration i've found out it was the squidguard common ACL "blk_BL_adv"
I imagine that many users use the shallalist blacklist, at the very moment i disabled that rule everything in the Man in The Middle worked like charm.

I'm not a programmer nor a squid expert, if anyone in this forum can contact the squidguard developers maybe they will find out if i was lucky or if there's a problem with squidguard, shallalist and ssl filtering

Sorry for my poor english.
Bye

I only block porn.

Another post relevant question.
Is there a way to white list a domain? Perhaps this will circumvent the above issue.
I tried : Services -> SquidProxy ->  ACL -> Whitelist: *facebook.com but that does nothing. perhaps the syntax is wrong or this is not what it's for?

Thanks,

The .crt I was referring to WAS exported from pfSense self-signed CA i created exactly for use with squid SSL.
Isn't custom website the only way to have client easily interact with that certificate (install it). I mean that involves making said website available, which I am not sure exactly easier. Please correct me if I am wrong.

thanks, the troubleshoot web page helped

Found issue and corrected.

CJB

Unchecking the 'transparent client ip' feature solved my problem.

Thank you very much,

Regards,
Joe

thanks, good point.
Ill experiment more with this.

http://downforeveryoneorjustme.com/www.eletrobraspiaui.com

It's actually down, or appears to be down.

No idea

The squid config General page has an Advanced Options button that you can use to expand the section that allows you to enter custom parameters.

If the squid package isn't to your liking then I don't know why you don't just spin up a Linux box, compile squid with whatever options you need and then just use that.

@Nachtfalke:

Status –> System Logs --> Settings
Dsiable "Log packets matched from the default pass rules put in the ruleset"

OR

Create a specific Firewall rule with destination "127.0.0.1" , action=allow and port=any and source=any and siable logging.
So traffic will match this specific rule and will be allowed but not logged.

Well, your first suggestion stops all pass logging it seems. The second suggestion didn't work. I'm guessing since the traffic is on the lo0 interface?