On 2016-10-29 20:40, paul.greene...@verizon.net wrote:
I've inherited a squid proxy at work; I'm new to squid, so this is
still on the learning curve. Unfortunately no one else in the office
is very good with squid either, so I'm attempting to be the resident
guru.
Our network is all in
It is supposed to be some headers in the http protocol; a description from the vendor:"Ensure that any proxy, firewall or content filtering applications or devices are not stripping header information from FTP or HTTP traffic, especially file size header information." In the SEPM error log, it is
On 30/10/2016 12:38 p.m., paul.greene.va wrote:
> This fixed the WSUS server, it wasn't the cache_peer parameter after all.
>
> acl inside dstdomain .mydomain.com
> always_direct allow inside
> never_direct allow all
> The SEPM might have an additional known issue (known by Symantec that is)
>
>
This fixed the WSUS server, it wasn't the cache_peer parameter after all.acl inside dstdomain .mydomain.comalways_direct allow inside never_direct allow all The SEPM might have an additional known issue (known by Symantec that is)If a proxy or a firewall is stripping, compressing, or encrypting
On 30/10/2016 4:40 a.m., paul.greene.va wrote:
>
> Our firewall guy says what he's seeing in his logs is that traffic destined
> for
> port 443, after it goes through the proxy, is trying to go straight to the
> vendor over the internet, rather than go through the upstream McAfee gateway
> as
I've inherited a squid proxy at work; I'm new to squid, so this is still on the learning curve. Unfortunately no one else in the office is very good with squid either, so I'm attempting to be the resident guru.Our network is all in private IP address space. A MS WSUS server and a Symantec
