Ah, okay. I see.
So what you need with Squid is a cache_peer, relaying relevant traffic
to that device.
# details of how Squid should connect to the device
cache_peer 172.27.46.253 parent 4434 0 originserver \
tls-cert=/path/to/server.ca
# which traffic to relay there
acl foo dstdomain foo.example.com
cache_peer_access 172.27.46.253 allow foo
never_direct allow foo
# permission for clients to make requests that reach that device
http_access allow localnet foo
Add more ACL conditions as needed to restrict the http_access line to
the appropriate clients.
Cheers
Amos
On 18/10/24 09:40, Piana, Josh wrote:
Hey Amos,
Thanks for replying.
To clarify on the test, port 4434 is the port that was assigned to get access to that device, one of our firewalls.
I looked at the old Squid config that we have, and it seems this was setup in a way that internal networks were not being passed through the proxy. This was done be either an ACL, or the PAC file, is what we're thinking. The issue is, we don't exactly know how to implement the PAC file on our new Squid box.
With that said, I agree with your statement that its difficult to troubleshoot an issue as opposed to go around it. Unfortunately, that's how it was done before and that's the direction our current management is going again. So I need to reconfigure the squid.conf file to ignore internal traffic, networks, and IP's, and only web filter and proxy internet connections. We can't just copy the old config because it doesn't carry over 1:1, and its an old version from 2.5.
Is there additional testing I could do or anything I should know to make this happen?
-----Original Message-----
From: squid-users <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of Amos Jeffries
Sent: Wednesday, October 16, 2024 11:45 PM
To: squid-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: Unable to access a device over port 4434
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 16/10/24 09:39, Piana, Josh wrote:
Amos,
Thank you for getting back to me and clarifying.
I ran this command:
#wget -Y off 172.27.46.253
Response:
--2024-10-15 16:36:15--
http://172.0.0.2/
7.46.253%2F&data=05%7C02%7Cjosh.piana%40hexcel.com%7Cf595ea81629e4e5db
45f08dcee5e2c12%7C4248050df19546d5ac9c0c7c52b04cae%7C0%7C0%7C638647335
455212558%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ZfzWSAFz5VpiHcYtQy4p
c%2BHj08G%2FvUSWdLaU2RckxlA%3D&reserved=0
Connecting to 172.27.46.253:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location:
https://0.0.0.172/.
27.46.253%2F&data=05%7C02%7Cjosh.piana%40hexcel.com%7Cf595ea81629e4e5d
b45f08dcee5e2c12%7C4248050df19546d5ac9c0c7c52b04cae%7C0%7C0%7C63864733
5458181374%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=z%2F5YhuDe5d2cz6KUm
TbGhMV6Dpgs3T%2B%2BrlqRewDCmCM%3D&reserved=0 [following]
--2024-10-15 16:36:15--
https://0.0.0.172/.
27.46.253%2F&data=05%7C02%7Cjosh.piana%40hexcel.com%7Cf595ea81629e4e5d
b45f08dcee5e2c12%7C4248050df19546d5ac9c0c7c52b04cae%7C0%7C0%7C63864733
5458181374%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=z%2F5YhuDe5d2cz6KUm
TbGhMV6Dpgs3T%2B%2BrlqRewDCmCM%3D&reserved=0
Connecting to 172.27.46.253:443... connected.
The TCP here is fully working, on both ports.
The followup hang you mentioned was likely due to a mistake in your followup test (that extra '4' typo?).
ERROR: The certificate of '172.27.46.253' is not trusted.
ERROR: The certificate of '172.27.46.253' doesn't have a known issuer.
The certificate's owner does not match hostname '172.27.46.253'
There you go. Two problems to resolve.
First Problem; unknown "Issuer" (aka root or intermediate CA certificate).
Please use this to find out what details need to be retrieved:
wget -v --no-proxy https://172.27.46.253/
Find the public CA certificate for the missing "Issuer".
Further tests with wget should use:
wget -v --no-proxy \
--ca-certificate=/path/to/server.ca https://172.27.46.253/
When wget test shows trust of the server certificate working, Squid should be configured to use it for checking too:
tsl_outgoing_options ca=/path/to/server.ca or
cache_peer 172.27.46.253 443 0 originserver tls-ca=/path/to/server.ca
Second Problem; mismatch between "172.27.46.253" and "Owner" (or maybe"SubjectAltName" fields).
The wget output when troubleshooting for the first problem should give more hints about what this means.
So with the errors given, would that stop us from connecting to it? Typically with sites with trust issues or certification issues, you can still bypass it. We'd like to do the same here if applicable.
One could, but your wget command does not.
FYI, It is also a bad idea to bypass unless you really have to.
Especially bad to bypass unknown amount of things when trying to identify reasons for failure.
Amos
_______________________________________________
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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
