Squid Returned to Packages *** PLEASE TEST ***
-
Verified. When you do not enable transparent mode it cores …. ::)
-
When you disable "allow traffic from interface" this alias goes away and would then rely on the whitelist.
At least the last time I tested this.
-
no transparent mode core dump fixed
-
Even with 2.6.5_1-p14 I get:
Jan 17 17:05:02 kernel: pid 2146 (squid), uid 0: exited on signal 6 (core dumped)
Jan 17 17:05:02 squid: No port defined
Jan 17 17:04:47 php: : SQUID is installed but not started. Not installing redirect rules.The service is marked as stopped.
My WebGUI port ist HTTPs on 445 and squid is set to 3128. Not likely they interfere.
What else can I watch out for? -
Squid p15 started!!!
-
When you disable "allow traffic from interface" this alias goes away and would then rely on the whitelist.
Okay, when I uncheck: "Allow users on interface" on the General settings tab, the:
Allow local network(s) on interface(s)
http_access allow localnet
entries do get removed from squid.conf as you thought.
At that point however, my whitelists and blacklists stop working altogether for some reason. What .conf files get updated when that setting is unchecked? I have compared squid.conf before and after, and all the other settings seems to be the same.
I also tried adding my subnet info in the: "Allowed subnets" section on the "Access control" tab - acls still don't work
-
When you disable "allow traffic from interface" this alias goes away and would then rely on the whitelist.
Okay, when I uncheck: "Allow users on interface" on the General settings tab, the:
Allow local network(s) on interface(s)
http_access allow localnet
entries do get removed from squid.conf as you thought.
At that point however, my whitelists and blacklists stop working altogether for some reason. What .conf files get updated when that setting is unchecked? I have compared squid.conf before and after, and all the other settings seems to be the same.
I also tried adding my subnet info in the: "Allowed subnets" section on the "Access control" tab - acls still don't work
thats the same problem i was having earlier. it seems to not rehash the missing value when you turn the "Allow User on Interface" option back on. should be easy enough to fix.
-
Hi all. I'm new to the forum and relatevely new to pfSense too.
I'm using pfSense since few months but I think it's a very great firewall: stable, full of features, very well implemented.
I installed the 2.6.5_1-p15 version of squid package on 1.0.1 release and it seems to work for me.
I configured it to act as a transparent proxy./usr/local/sbin/squid status
2007/01/17 18:39:20| Squid is already running! Process ID 11629/var/squid/log/access.log and /var/squid/log/cache.log are populated.
I'm writing here because I don't understand if there is a way to view squid access logs in the webConfigurator.
I don't see anything in packages logs. Have you planned to implement this feature?I think I'll try to send access.log to a remote syslog server where to run a log analyzer as SARG.
Thanks you very much for all your great work.
-
@ jahonix
What version of pfSense are you running? Please be sure to be running a version beyond 1.0.1. You must be using a snapshot of some kind or else squid will not start. http://snapshots.pfsense.com/FreeBSD6/RELENG_1/ If the update doesn't help, wipe the machine clean and start with a full iso clean install.
-
I have to debug the "whitelist access only" to see why it doesn't work. The only important part with the acls is the ordering. and allowed_subnets and localnet are last in the queue. I have no idea on this one yet.
With regards to access to the logs, none of that is currently implemented. Access to the cache.log is not such a problem. Since that one is small and for debugging purposes only. The access log however needs something akin to sarge or webalizer for generating anything usefull.
Syslog would be a workaround. Although by far the easiest way to move the logs around. Although this would be a bad idea on a larger installation.
-
@ jahonix
What version of pfSense are you running?1.0.1-SNAPSHOT-01-13-2007
built on Sun Jan 14 15:07:53 EST 2007 -
Thanks, databeestje, we have a working squid now. p15 finally did it.
-
well, here it still dumps, but no more at startup. no matter whether transparent or not.
i'm running 1.0.1-SNAPSHOT-01-13-2007 and just download the next one. squid is p15.squid starts without problems but dumps at any access.
another thing: when i disable 'allow on interface' but include the interface's ip-subnet to the allowed subnets it denies me access (and no dump!).
so, the download is ready, i'll post again after update.
edit:
now i'm running 1.0.1-SNAPSHOT-01-19-2007 and it still is the same, core dump at access.
sure there are no dependencies that need updates? -
better check if the acl(s) you use are in the new line by line format.
so no , in there.
-
Has anyone had any luck so far in getting a wildcard to work in the blacklist or somehow been able to create a 'whitelist only' proxy?
-
There is still some wrong …
Clean install of 1.0.1 iso, immediate upgrade to latest snapshot (2007-01-19), install squid.It starts and seems to be running on the default port (3128), but if I try to change anything on the General settings page (i.e. Admin e-mail, displayed hostname, PORT), I get the notorious:
The following input errors were detected:
You can not run squid on the same port as the webguiAny hints? I'm running pfSense with the WEBGUI on the default HTTPS-Port of 443 and I'm trying to set the Proxy-Port to 8080 ...
-
The following input errors were detected: You can not run squid on the same port as the webgui
Change the webGUI port to: HTTP:81, save it and set it back to https:443
This cured it over here on 2 installsMaybe it's just the unused reference to HTTP:80 that squid doesn't like, but I don't know.
I have set squid to transparent mode on port 80, FWIW -
found it!
i had to activate and deactivate the upstream-proxy! no idea why that but it solved it!! p15 running!!
-
I gave it a test run, p15 seems to be working great for me, I will update you if I find out anything new in my logs!
-
Setting the WebGUI-Port solved it.
No need to set it to http:81 and back to https:443.Just specifying a port in the WebGUI-Field does the trick (even if it's the default https port of 443).
Which gives me the suspicion that the "WebGUI-Port-Field is used for a RegEx - and an empty RegEx matches all … I'll test if a WebGui-Port of 80 prevents a Proxy-Port of 8080 or 8000 ...