Re: [squid-users] Squid communications proxy dilemma

[Garri Djavadyan]

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 private IP address space. A MS WSUS server and a
Symantec Endpoint Protection Manager server need to get through the
squid proxy to get out to MS and Symantec respectively for their
updates. Some other servers are coming online in the near future that
will also need to get out to their respective vendors to get updates,
including a Redhat Satellite server.

For these WSUS and SEPM servers, they have to go through the proxy I'm
working with, through a Cisco firewall, upstream to a McAfee web
gateway, and through another gateway after that. After traffic gets
past that Cisco firewall, a different networking group is responsible
for any upstream configuration

None of our other servers, except these specialty servers that need to
get out to their respective vendors for updates, have direct access to
the internet.

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 required, and thus, the traffic is
getting dropped by the Cisco firewall. I did a packet capture test
with the McAfee gateway guy, and he confirmed that no traffic coming
from either either the WSUS or the SEPM is reaching his gateway.

I thought this line in the squid.conf file should send traffic from
our proxy to the upstream McAfee gateway, but maybe I'm
misunderstanding the intent of the cache_peer parent parameter.

cache_peer   parent8080  3130
proxy-only no-query no-netdb-exchange default login=username:password

(if placement of this cache_peer parameter matters, its currently near
the end of the squid.conf file)

As a test, I configured internet explorer on the WSUS server to use
the proxy for internet access, Without configuring for the proxy, IE
can't go anywhere except the local network. IE can hit http websites
(i.e. www.cnn.com) when it's configured to use the proxy, but not
https websites.

The Safe_ports and SSL_ports list is the same as the squid.conf
defaults.

This is squid 3.3 running on Redhat 7.

Any suggestions or pointers?

PG
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


Please, use plain text (not HTML) for messages next time, as it hurts 
people reading messages on web archive [1]. Also, IMO, it increases the 
chances a message would be answered. Thanks.


[1] 
http://lists.squid-cache.org/pipermail/squid-users/2016-October/013308.html


Garri
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Default state for the option generate-host-certificates

[Amos Jeffries]

On 29/10/2016 8:18 a.m., Garri Djavadyan wrote:
> On 2016-10-28 18:39, Yuri Voinov wrote:
>> It seems bug.
> 
> 
> On 2016-10-28 19:53, Alex Rousskov wrote:
>>> Is it a bug, documentation error or I simply missed something?
>>
>> It is a bug IMO. The documented intent sounds worth supporting to me.
> 
> 
> Thanks. I've opened the report [1].
> 
> [1] http://bugs.squid-cache.org/show_bug.cgi?id=4627
> 

Thanks. I've fixed the docs in Squid-3, will sho up whenever teh next
3.5 reease happens.

For Squid-4 I am making Squid actually have those defaults. That will go
in soon after the change passes pre-commit build testing.

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid communications proxy dilemma

[paul . greene . va]

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 stating that it failed to get file size header information - but I don't know exactly where that would be getting removed. If its not squid, it could be anywhere upstream from me I've got a "Squid Proxy Server 3.1 - Beginners Guide" but this doesn't go into that much about modifying packet headers, excepts for headers to obfuscate client information for security reasons. I'm pretty sure squid isn't doing anything about the packet headers since this config file is so basic, so maybe this has gotten outside the scope of a squid mailing list. On 10/29/16, Amos Jeffries wrote: 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)> > If a proxy or a firewall is stripping, compressing, or encrypting content length > packet headers, that'll break SEPM too. (SEPM uses port 80 by default, so > theoretically it should have been getting out)> > Is there a parameter in squid that would do that? (so I can see if it is > configured or not) The squid.conf is 90% of the default file, with just a few > tweaks needed for our environment.Squid is HTTP software, it does not do anything with the TCP packetlevel of things.If by "packets" you actually meant "HTTP messages", then ... HTTP isdesigned with middleware alterations of the message along the way. Anysoftware which cannot handle that is broken.Likewise any software using port 80 which cannot handle HTTP on the portis broken.Amos___squid-users mailing listsquid-users@lists.squid-cache.orghttp://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid communications proxy dilemma

[Amos Jeffries]

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)
> 
> If a proxy or a firewall is stripping, compressing, or encrypting content 
> length 
> packet headers, that'll break SEPM too. (SEPM uses port 80 by default, so 
> theoretically it should have been getting out)
> 
> Is there a parameter in squid that would do that? (so I can see if it is 
> configured or not) The squid.conf is 90% of the default file, with just a few 
> tweaks needed for our environment.

Squid is HTTP software, it does not do anything with the TCP packet
level of things.

If by "packets" you actually meant "HTTP messages", then ... HTTP is
designed with middleware alterations of the message along the way. Any
software which cannot handle that is broken.

Likewise any software using port 80 which cannot handle HTTP on the port
is broken.

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid communications proxy dilemma

[paul . greene . va]

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 content length packet headers, that'll break SEPM too. (SEPM uses port 80 by default, so theoretically it should have been getting out)Is there a parameter in squid that would do that? (so I can see if it is configured or not) The squid.conf is 90% of the default file, with just a few tweaks needed for our environment.PGOn 10/29/16, Amos Jeffries wrote: 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 > required, and thus, the traffic is getting dropped by the Cisco firewall. I did > a packet capture test with the McAfee gateway guy, and he confirmed that no > traffic coming from either either the WSUS or the SEPM is reaching his gateway.> > I thought this line in the squid.conf file should send traffic from our proxy to > the upstream McAfee gateway, but maybe I'm misunderstanding the intent of the > cache_peer parent parameter.> > cache_peer   parent8080  3130  proxy-only > no-query no-netdb-exchange default login=username:password> cache_peer configures the *how* of traffic sent to that gateway. Whichtraffic uses it is configured by other directives (cache_peer_access,always_direct, never_direct, peer_direct, nonhierarchical_direct) anddepends on the type of traffic.NP: the above also indicates the connection(s) are plain-text HTTP. Ifyou are using interception then HTTPS traffic cannot go through thatlink. Since HTTPS requires end-to-end security, the cache_peerconnection needs to use 'ssl' options for intercepted port 443 to use itsafely.> (if placement of this cache_peer parameter matters, its currently near the end > of the squid.conf file)> > As a test, I configured internet explorer on the WSUS server to use the proxy > for internet access, Without configuring for the proxy, IE can't go anywhere > except the local network. IE can hit http websites (i.e. www.cnn.com) when it's > configured to use the proxy, but not https websites.> > The Safe_ports and SSL_ports list is the same as the squid.conf defaults.> > This is squid 3.3 running on Redhat 7.> > Any suggestions or pointers?Assuming you are using explicit/forward proxy, add this to your squid.conf: never_direct allow allif that dont work by itself you may need these as well: prefer_direct off nonhierarchical_direct offYou should not have any existing lines with those directives or withalways_direct. If you do the placement might matter.Amos___squid-users mailing listsquid-users@lists.squid-cache.orghttp://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid communications proxy dilemma

[Amos Jeffries]

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 
> required, and thus, the traffic is getting dropped by the Cisco firewall. I 
> did 
> a packet capture test with the McAfee gateway guy, and he confirmed that no 
> traffic coming from either either the WSUS or the SEPM is reaching his 
> gateway.
> 
> I thought this line in the squid.conf file should send traffic from our proxy 
> to 
> the upstream McAfee gateway, but maybe I'm misunderstanding the intent of the 
> cache_peer parent parameter.
> 
> cache_peer   parent8080  3130  proxy-only 
> no-query no-netdb-exchange default login=username:password
> 

cache_peer configures the *how* of traffic sent to that gateway. Which
traffic uses it is configured by other directives (cache_peer_access,
always_direct, never_direct, peer_direct, nonhierarchical_direct) and
depends on the type of traffic.

NP: the above also indicates the connection(s) are plain-text HTTP. If
you are using interception then HTTPS traffic cannot go through that
link. Since HTTPS requires end-to-end security, the cache_peer
connection needs to use 'ssl' options for intercepted port 443 to use it
safely.


> (if placement of this cache_peer parameter matters, its currently near the 
> end 
> of the squid.conf file)
> 
> As a test, I configured internet explorer on the WSUS server to use the proxy 
> for internet access, Without configuring for the proxy, IE can't go anywhere 
> except the local network. IE can hit http websites (i.e. www.cnn.com) when 
> it's 
> configured to use the proxy, but not https websites.
> 
> The Safe_ports and SSL_ports list is the same as the squid.conf defaults.
> 
> This is squid 3.3 running on Redhat 7.
> 
> Any suggestions or pointers?

Assuming you are using explicit/forward proxy, add this to your squid.conf:

 never_direct allow all

if that dont work by itself you may need these as well:

 prefer_direct off
 nonhierarchical_direct off

You should not have any existing lines with those directives or with
always_direct. If you do the placement might matter.

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] Squid communications proxy dilemma

[paul . greene . va]

 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 Endpoint Protection Manager server need to get through the squid proxy to get out to MS and Symantec respectively for their updates. Some other servers are coming online in the near future that will also need to get out to their respective vendors to get updates, including a Redhat Satellite server.For these WSUS and SEPM servers, they have to go through the proxy I'm working with, through a Cisco firewall, upstream to a McAfee web gateway, and through another gateway after that. After traffic gets past that Cisco firewall, a different networking group is responsible for any upstream configurationNone of our other servers, except these specialty servers that need to get out to their respective vendors for updates, have direct access to the internet.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 required, and thus, the traffic is getting dropped by the Cisco firewall. I did a packet capture test with the McAfee gateway guy, and he confirmed that no traffic coming from either either the WSUS or the SEPM is reaching his gateway.I thought this line in the squid.conf file should send traffic from our proxy to the upstream McAfee gateway, but maybe I'm misunderstanding the intent of the cache_peer parent parameter.cache_peer       parent    8080  3130  proxy-only no-query no-netdb-exchange default login=username:password(if placement of this cache_peer parameter matters, its currently near the end of the squid.conf file)As a test, I configured internet explorer on the WSUS server to use the proxy for internet access, Without configuring for the proxy, IE can't go anywhere except the local network. IE can hit http websites (i.e. www.cnn.com) when it's configured to use the proxy, but not https websites.The Safe_ports and SSL_ports list is the same as the squid.conf defaults.This is squid 3.3 running on Redhat 7.Any suggestions or pointers?PG
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users