Alex, Thank you for your response! Unfortunately, this squid.conf I'm using was put together by one of our technicians that actually knew Linux and was staffed here at this location for nearly 20 years. He ran this off of a CentOS box using Squid 2.5 - and it was woefully out of date as you can imagine. I now understand that Squid 5.5, while newer, is actually out of date as well. I regret installing and working off of this because I jused assumed the "yum" install command for the Squid distro would give me the most recent, known-good, software. That's completely on me. From how I understand it, his intentions for internal users accessing internal resources, would skip authentication altogether. Here's a small piece, with his notes included, of why I think that. ------------------------------------------------------------------------------------------------------------------------ # ---------------------------------------------------------------------------- # allow without authentication # these rules allow certain connects without user authentication # these allow any protocol/method/etc # ***** IMPORTANT ***** # Adding to these lists also exempts from all content filtering. # In particular, executables will be allowed to download! # ***** IMPORTANT ***** # allow connects to local destinations without authentication # by domain name from URL http_access allow local_dst_dom http_reply_access allow local_dst_dom # by IP address name resolves to http_access allow local_dst_addr http_reply_access allow local_dst_addr ------------------------------------------------------------------------------------------------------------------------ The "http_access allow local_dst_dom" and the following reply statement seems to point toward his intentions when writing this. The only thing in the old config this was referencing was this, and to me, it doesn't make sense: # acl local_dst_dom dstdomain arcgate It's worth noting that despite how awkward this seems, it DOES work. On the old web proxy we're currently still running live. I've gone as far as swapping out just the authentication settings and keeping the entire old config, but it still doesn't work. I've setup a realmd/sssd/kerberos backend instead of Samba/Windbind that the old server uses. To state the issue we're having again - internal resources connecting to other internal resources fails via hostname, but works when using IP. I was able to troubleshoot and conclude DNS was not the issue, as all other aspects are working as intended and they certainly do use DNS. Also pings resolve using hostname from the new squidbox so that implies that DNS is working as expected. Ultimately, here's what I think we want, please feel free to poke holes in it: Allow clients who are accessing other internal rersources to be able to browse to it using its hostname, without needing authentication first. I do intend on adding those parameters you mentioned to the logs so I can get better details within. I also need to look into how to use the debugging features, I'm not familiar with it at all. I apologize for the wall of text, looking forward to what you guys have to say about this. Thanks, Josh -----Original Message----- From: squid-users <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of Alex Rousskov Sent: Wednesday, August 28, 2024 2:31 PM To: squid-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: Unable to access internal resources via hostname Caution: This email originated from outside of Hexcel. Do not click links or open attachments unless you recognize the sender and know the content is safe. On 2024-08-28 14:18, Alex Rousskov wrote: > On 2024-08-28 11:24, Piana, Josh wrote: > >> Here's the log and (I think) relevant ACL's? > > According to your access.log, Squid denies problematic CONNECT > requests with HTTP 407 errors responses. Usually, that means those > requests match an "http_access deny" rule. Clearly, you expect an > "allow" outcome instead, but it is difficult (for me) to figure out > where your expectations mismatch reality; there are no rules that > explicitly mention hexcelssp domain, for example: Which "http_access > allow" rule do you expect those denied requests to match? Sorry, I probably misinterpreted those access.log records: It looks like the denied (TCP_DENIED/407) access is something you actually expect because you want that test request to be authenticated. The client supplies the necessary credentials in the second request, and then that second request fails with a (rather generic) HTTP 500 error code, without contacting the origin server. I am guessing that you are concerned about that second request/transaction rather than the first one. Squid generates HTTP 500 errors for a variety of different reasons. Are there any messages in cache.log (at default debugging level) that correspond to these failing test transactions? If there are none, please add %err_code/%err_detail to your access_log logformat so that Squid logs more information about the problem to access.log (see logformat and access_log directives in squid.conf.documented for details). Thank you, Alex. > Also, does mgr:ipcache cache manager query confirm that Squid has read > your /etc/hosts file and cached the record you expect it to use? > > Alex. > > >> --------------------------------------------------------------------- >> -------------------------------------- >> # /var/log/squid/access.log results for internal conflicts >> >> 28/Aug/2024:10:57:17 -0400.234 10.46.49.190 TCP_DENIED/407 4132 >> CONNECT hexcelssp:443 - HIER_NONE/- text/html >> 28/Aug/2024:10:57:17 -0400.253 10.46.49.190 NONE_NONE/500 0 CONNECT >> hexcelssp:443 JPIANA@AD.<DOMAIN>.COM HIER_NONE/- - >> 28/Aug/2024:10:57:17 -0400.380 10.46.49.190 TCP_DENIED/407 4132 >> CONNECT hexcelssp:443 - HIER_NONE/- text/html >> 28/Aug/2024:10:57:17 -0400.399 10.46.49.190 NONE_NONE/500 0 CONNECT >> hexcelssp:443 JPIANA@AD.<DOMAIN>.COM HIER_NONE/- - >> --------------------------------------------------------------------- >> -------------------------------------- >> >> # acl all src all >> >> acl src_self src 127.0.0.0/8 >> acl src_self src 10.46.11.69 >> >> acl dst_self dst 127.0.0.0/8 >> acl dst_self dst 10.46.11.69 >> >> acl from_arc src 10.46.0.0/15 >> >> acl local_dst_addr dst 10.0.0.0/8 >> acl local_dst_addr dst 172.0.0.0/8 >> acl local_dst_addr dst bldg3.<domain>.com acl local_dst_addr dst >> bldg5.<domain>.com >> >> # these keep URLs of popular local servers from being forwarded acl >> local_dst_dom dstdomain arcgate >> >> # allow connects to local destinations without authentication # by >> domain name from URL >> http_access allow local_dst_dom >> http_reply_access allow local_dst_dom >> >> # by IP address name resolves to >> http_access allow local_dst_addr >> http_reply_access allow local_dst_addr >> >> # allow trusted hosts without authentication # these are just ip's on >> the 10.46.11.x network acl authless_src src "/etc/squid/authless_src" >> http_access allow authless_src >> http_reply_access allow authless_src >> --------------------------------------------------------------------- >> -------------------------------------- >> >> -----Original Message----- >> From: squid-users <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx> On >> Behalf Of Matus UHLAR - fantomas >> Sent: Wednesday, August 28, 2024 10:47 AM >> To: squid-users@xxxxxxxxxxxxxxxxxxxxx >> Subject: Re: Unable to access internal resources via >> hostname >> >> Caution: This email originated from outside of Hexcel. Do not click >> links or open attachments unless you recognize the sender and know >> the content is safe. >> >> >> On 28.08.24 14:20, Piana, Josh wrote: >>> Hello Squid Support, >> >> This squid user forum FYI >> >>> We are unable to get to internal resources via hostname but using >>> the IP address works fine. Immediately, I thought this was DNS but >>> when I checked the /etc/resolv.conf/ file it was pointing correctly >>> to our Windows DNS server and we can ping all devices using their >>> hostname, just not when browsing to it. This leads me to believe >>> something may be wrong with our squid config. >> >> hard to guess without seeing logs or ACL's. >> >> >> -- >> Matus UHLAR - fantomas, uhlar@xxxxxxxxxxx ; >> http://www/. >> fantomas.sk%2F&data=05%7C02%7Cjosh.piana%40hexcel.com%7C2db72264caa04 >> f1fd80d08dcc78f9245%7C4248050df19546d5ac9c0c7c52b04cae%7C0%7C0%7C6386 >> 04666668859787%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2 >> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Z7cUEdNvInDAJ >> PwgQJhXWSK3H2mkAPe4CNcfYJFyy6M%3D&reserved=0 >> Warning: I wish NOT to receive e-mail advertising to this address. >> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. >> It's now safe to throw off your computer. >> _______________________________________________ >> squid-users mailing list >> squid-users@xxxxxxxxxxxxxxxxxxxxx >> https://lis/ >> ts.squid-cache.org%2Flistinfo%2Fsquid-users&data=05%7C02%7Cjosh.piana >> %40hexcel.com%7C2db72264caa04f1fd80d08dcc78f9245%7C4248050df19546d5ac >> 9c0c7c52b04cae%7C0%7C0%7C638604666674016161%7CUnknown%7CTWFpbGZsb3d8e >> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0 >> %7C%7C%7C&sdata=%2B%2B7inZxg2LEmB2KFVWmtn64FG8SwHpEZeEyAjhNClnU%3D&re >> served=0 _______________________________________________ >> squid-users mailing list >> squid-users@xxxxxxxxxxxxxxxxxxxxx >> https://lis/ >> ts.squid-cache.org%2Flistinfo%2Fsquid-users&data=05%7C02%7Cjosh.piana >> %40hexcel.com%7C2db72264caa04f1fd80d08dcc78f9245%7C4248050df19546d5ac >> 9c0c7c52b04cae%7C0%7C0%7C638604666674016161%7CUnknown%7CTWFpbGZsb3d8e >> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0 >> %7C%7C%7C&sdata=%2B%2B7inZxg2LEmB2KFVWmtn64FG8SwHpEZeEyAjhNClnU%3D&re >> served=0 > > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > https://list/ > s.squid-cache.org%2Flistinfo%2Fsquid-users&data=05%7C02%7Cjosh.piana%4 > 0hexcel.com%7C2db72264caa04f1fd80d08dcc78f9245%7C4248050df19546d5ac9c0 > c7c52b04cae%7C0%7C0%7C638604666674016161%7CUnknown%7CTWFpbGZsb3d8eyJWI > joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7 > C%7C&sdata=%2B%2B7inZxg2LEmB2KFVWmtn64FG8SwHpEZeEyAjhNClnU%3D&reserved > =0 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx https://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx https://lists.squid-cache.org/listinfo/squid-users
