Eric,
That’s swell. Really Appreciated. Drive SAFE.
Ken
The port81 line has nothing to do with the cache manager. It is handled by apache and used for the block pages, update acclereator and webgui. It also should redirect to the webgui (https 444) if you try to get without an url.
Eric,
thx for your config file.
Most interesting fact is, you don’t use a password!
Maybe, this is just the problem.
Thanks Arne, that reply was very helpful.
A little bit of thought saves a lot of work.
Bernhard,
I am not sure what your talking about here in this thread. LOL…
I am not the one with the Web Proxy issue, but rather Kenneth whom I am trying to advise. The Web Proxy actually works in my install, although it was a bear to set up initially.
Kenneth, you could pick any port, in theory that isn’t a standard used port, and its OK. 444 is the port Used to Connect to Squid Cache Manager Web GUI and 801 is the port of connection into the actual Cache server.
This means you could technically have several “Cache Servers” running on different ports, or even the same port on different IP addresses, depending on the amount of HTTP Traffic flowing through your network. 1 : ~ relationship
Notice the down arrow to the right of the IP:801 in my screenshot. It is a selection box so you can manage whatever and whichever “Cache Server” your data is on.
Another side note, not only does a person manage the cache from port 801, but 801 and 3129, are the 2 ports used to pass traffic through the Proxy. 1 is the inbound, the other, the outbound… Look back in my squid config for the word intercept.
Lets just say that I work on a lot of stuff in my field and might have a tid-bit of experience with this sorta thing. In application to Squid, ehhh, its ok, but its a basic concept with inbound and outbound caching of bits and pieces of traffic over HTTP. Its a heck of a bandwidth saver if you can get it up and running.
Another note… make sure this is turned on. Nothing worse than not being notified in logs if something gets blocked.
Both of these ports are configurable from the prospective of the GUI, down in the picture below.
Eric
Kenneth,
I found your problem, because I was just literally able to replicate your problem on my production IPFire. Figured it was Off-Peak hours so I could toy with it slightly.
Lets do show and tell here…
Here is what I was able to force to happen, on my working system.
Quick test to see login passwords… See notes in green on picture…
I added a password after testing to the passwords box on the IPFire Web Proxy screen… This is where I figured out what I believe to be your problem, based on testing and reading back through your posts.
What did I do to cause this? I added a password to this box.
I clicked “Save and Restart” button on the same page to recycle squid services and re-read config.
After doing so, I closed my browser tabs, went back to the cachemanager login page, and tried logging in with crap passwords again, and it blocked me.
Each time I changed the password, I run:
cat squid.conf to see if the password was updating. Sure was…
Go check out your GUI and your squid.conf and look for your password:
cachemgr_passwd Hawaii all
I took it a little further in testing… Toying more, and found exactly your problem… Now I am pretty damn sure I hit the bullseye…
the URI rotate, and every other URI path under the cache manager started failing
cache_object://x,x,x.1/via_headers for example…
and…drumroll please… The problem is…
There is a password in the Web Proxy field, just below the email you entered. Delete that password, Click “Save and Restart”, then empty your cache, close your browser, open it back up and try it again. Almost positive it will work!
I told you in the beginning that I had seen this happen to me in the past and it took me this long to figure it back out, because I just couldn’t remember. There is something jacked up in the squid proxy code that if you have a password in there, it will allow you to the cache manager menu but will choke on all of its URI paths.
Give that a shot and see what happens!
Eric
1 Like
Hi Kenneth,
I see your picture, but I can’t determine if what I posted actually helped resolve your ability to click and load any of the links in that cache manager menu.
Can you click through, and actually get the pages to load, without getting the red screen of death (which complain about authenticating), for each of the links in that menu?
Please confirm.
Thx
Eric
Eric,
many thx that you really tried with setting a password. 
This was/is the main problem Kenneth and I reported.
You tried to help with posting of some screenshots ( not even actual? ) and many basic explanations, but you did show your real configuration very late in this thread. This (little) information showed the problem!
Thus our conversation sometimes seemed to be not really consistent.
Could you post a bug at bugzilla, please? You got this error earlier and you have more insight in the pitfalls of the proxy configuration.
Eric,
That was meant to be a Hooray!
Thanks greatly. Now I’ve moved on to
wondering why the IPS log file is always blank - possible
that my area is not part of any scan or attack surface.
Thanks, you have done much work and can’t express the relief of
having not to worry or wonder why that was.
Hope that it is beneficial to other users. Perhaps should petition the
manager of the site to allow editing the post to make it easy to comprehend.
Had hoped the fire hydrant looking like a Dalmatian and titled tah-rah-boom-b-a
was A-List. Loved your Mustang - drove a three speed convertible in 1966 San Diego.
Macho 351 Windsor motor.
Ken
Sure Bernhard, I’d be happy to post a bug note for dev. I will try my best to find thst site, but can you post back the url.
Eric
Hey Kenneth,
I seen the Fire Hydrant and assumed it was possible that you was on the network team at a Fire Dept or that you was a firefighter.
I like the feel of Mustangs. Nice cars.
In any event, if you need some help with IPS, I would be happy to help.
Do me a favor and start a new thread, and I will jump over there to help you out. IPS shouldn’t be as difficult to correct.
Eric
Thank you for that,
That was totally not what I expected it to be, but I will head in that direction.
Much Appreciated…
Bug 12451 has been logged for review referencing this thread of convo.
Thx
1 Like
Eric,
A second thought: the solution basis was No Password and Unrestricted IP addresses): 192.168.5.2 (Blue) 192.168.2.2 (Green) 192.168.8.1 (red).
The worry is Unrestricted IP addresses might by pass the firewall, which in-itself defeat the Firewall.
What’s your thought?
Hi Kenneth,
To prevent a hodgepodge of confusion between topics, could you create a new thread topic for IPS if that happens to be what your asking.
Be happy to help, just trying to prevent confusion on that front.
Eric
1 Like
Thanks Eric,
- New Topic added. and have received an idea to
test an eicar web page; firewall blocked access to
that page but no reason was given in the Log file
since eicar is not part of the rule-set. Hmm?
Meanwhile checked a few DNS Protocol and that
caused 100s of log results - regretfully way
too many.
- regarding our conversation about the Cache Management
could you please reconfirm adding the cache’s IP to the
White List (that IP 192.168.2.2 is the BLUE Wireless).
Doesn’t adding that to the Whitelist defeat the Firewall?
I’ve removed that IP from the white list thinking to
add it back when it is necessary to examine the cache.
Looking forward to your reply,
Ken
If your referring to the Unrestricted IP box in the Web Proxy settings, that is for a single IP . x.x.x.x/32… The box above it is for the Full Network /24. Those Group boxes are a subset of the Cache Manager, not Browser Traffic. They should have named it something like “Allow access to Cache Manager” to prevent confusion.