[squid-users] Unable to access a device over port 4434

Fri Oct 18 05:59:05 UTC 2024

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 at lists.squid-cache.org> On Behalf Of Amos Jeffries
> Sent: Wednesday, October 16, 2024 11:45 PM
> To: squid-users at lists.squid-cache.org
> Subject: Re: [squid-users] 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 at lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users