Re: [squid-users] Transparent proxy http 3xx status issues

[Ben Goz]

By the help of God.

I'm using squid 4.15

When I said transparent proxy I meant to say that I'm using tproxy
configuration with iptables redirection.

Squid returns http 503 and when bypassing squid I see http 302.

What do you think is the best way to overcome this problem?

Thanks,
Ben

‫בתאריך יום ה׳, 2 בספט׳ 2021 ב-16:25 מאת ‪Amos Jeffries‬‏
<‪squ...@treenet.co.nz‬‏>:‬
>
> On 2/09/21 10:43 pm, Ben Goz wrote:
> > By the help of God.
> >
> > I configured squid to be transparent proxy with ssl bump
> > I saw that when the users trying to access next.co.il or pinterest.com
> > They observed squid errors sometimes it's connection refused sometimes
> > connection timed out
> >
> > But when I bypass squid proxy it's working fine.
> >
> > I saw that next.co.il sends http 302 redirect messages
> > Maybe I'm missing some configuration that doesn't send back those
> > packets to the users?
> >
>
> There are several things you could do, but which is correct depends on ...
>
> Which version of Squid are you using?
>
> By "transparent proxy" what configuration do you mean?
>
> What message is Squid sending to that server when it gets a 302 redirect?
>
>
> Amos
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://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] Transparent proxy http 3xx status issues

[Amos Jeffries]

On 2/09/21 10:43 pm, Ben Goz wrote:

By the help of God.

I configured squid to be transparent proxy with ssl bump
I saw that when the users trying to access next.co.il or pinterest.com
They observed squid errors sometimes it's connection refused sometimes
connection timed out

But when I bypass squid proxy it's working fine.

I saw that next.co.il sends http 302 redirect messages
Maybe I'm missing some configuration that doesn't send back those
packets to the users?



There are several things you could do, but which is correct depends on ...

Which version of Squid are you using?

By "transparent proxy" what configuration do you mean?

What message is Squid sending to that server when it gets a 302 redirect?


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

Re: [squid-users] transparent proxy upgrade 3.5 to 4.12, Error parsing SSL Server Hello Message on FD XX

[Amos Jeffries]

On 23/06/20 2:50 am, Tanner wrote:
> I have squid set up as a transparent outbound proxy using version 3.5.
> When upgrading to 4.12, I am seeing an error "Error parsing SSL Server
> Hello Message on FD XX" that did not happen before. Here is my config:
> 
...

> 
> Previous to 4.12, if I tried to upgrade to any v4 or v5 of squid, I
> would get an issue with "inappropriate fallback" when going to some
> sites supporting TLS 1.3 (but not all). This appears to have been
> resolved, but this "Error parsing SSL Server Hello Message" is new. Is
> there something that should change in my config? Can anyone tell me what
> this error means?

It may be resolved with this patch:
 


Otherwise you could try the latest Squid-5.

If neither of those work, v5 should have better debugging to help track
down what the issue actually is.

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

Re: [squid-users] Transparent proxy for WiFi users

[Amos Jeffries]

On 03/01/18 10:15, Yuri wrote:


03.01.2018 02:13, Amos Jeffries пишет:

On 03/01/18 02:48, Roberto Carna wrote:

Dear, I've setup a Squid transparent proxy + Squidgard on pfSEnse 2.4
in order to filter HTTP and HTTPS web content for different types of
WiFi clients on my company:

- Android (different versions)
- Notebooks Windows 7/10
- Iphone
- Etc.

In some cases, depending on the device Operating System, some apps
experiment problems, for example Facebook and some others.


The main cause of these problems is that when the same vendor is
authoring both the server software and the client "app" (or client
device OS). They can (and often do) hard-code TLS certificate checks
into their client code to detect and immediately fail in the presence
of MITM in the encryption.

Following that, SSL-Bump is still very much an ongoing project.
Selecting even a slightly older Squid version can lead to TLS features
not being supported. So when problems occur the best option is still
to upgrade to the very latest release before debugging further - today
that would be squid-4.0.22 beta.




Which is the best solution in order to setup a TRANSPARENT proxy
service in a heterogeneous scenario with diferenbt types of devices,
and running in the best mode with the minimum number of problems???


The _only_ solution is not to decrypt such traffic (the splice
action). How you determine which traffic is having such special trust
given to it is up to you. The TLS SNI is provided by the peek action
at SSL-Bump step 1.

Well, you can do it when you want. For example, take a look (for example):

https://stackoverflow.com/questions/4461360/how-to-install-trusted-ca-certificate-on-android-device

or on this:

http://wiki.cacert.org/FAQ/ImportRootCert

Or, in your case,  you can differentiate users by, for example, by
network and pass wifi users to splice rule. Much approaches exists.


NP: none of which work when the application is checking the fingerprint 
of the CA certificate against a hard-coded value defined by the vendor. 
These are simply ways to make the SSL-Bumping process work without 
"untrusted CA" warnings *if* bumping is already possible.






Or do I have to move to a scenario with a defined proxy in another
server, and automatically established in clients with DHCP ???



Explicit proxy is definitely better for HTTP than interception proxy.
That is true regardless of what else is going on. So worth doing *if*
you can.

Oh, really? You have forgotten about beatiful 252 option in DHCP, about
WCCP interception, and such other good things. In other world,


No, I am not.

DHCP, WPAD/PAC, and such are just ways to auto-configure explicit proxy 
*not* interception proxy.


WCCP is just a way to tunnel packets to the proxy machine. Explicit 
proxy does not require that additional tunnel complexity.
 If you combine WCCP with interception it becomes "interception proxy", 
not "explicit proxy".



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

Re: [squid-users] Transparent proxy for WiFi users

[Yuri]

03.01.2018 02:13, Amos Jeffries пишет:
> On 03/01/18 02:48, Roberto Carna wrote:
>> Dear, I've setup a Squid transparent proxy + Squidgard on pfSEnse 2.4
>> in order to filter HTTP and HTTPS web content for different types of
>> WiFi clients on my company:
>>
>> - Android (different versions)
>> - Notebooks Windows 7/10
>> - Iphone
>> - Etc.
>>
>> In some cases, depending on the device Operating System, some apps
>> experiment problems, for example Facebook and some others.
>
> The main cause of these problems is that when the same vendor is
> authoring both the server software and the client "app" (or client
> device OS). They can (and often do) hard-code TLS certificate checks
> into their client code to detect and immediately fail in the presence
> of MITM in the encryption.
>
> Following that, SSL-Bump is still very much an ongoing project.
> Selecting even a slightly older Squid version can lead to TLS features
> not being supported. So when problems occur the best option is still
> to upgrade to the very latest release before debugging further - today
> that would be squid-4.0.22 beta.
>
>
>>
>> Which is the best solution in order to setup a TRANSPARENT proxy
>> service in a heterogeneous scenario with diferenbt types of devices,
>> and running in the best mode with the minimum number of problems???
>
> The _only_ solution is not to decrypt such traffic (the splice
> action). How you determine which traffic is having such special trust
> given to it is up to you. The TLS SNI is provided by the peek action
> at SSL-Bump step 1.
Well, you can do it when you want. For example, take a look (for example):

https://stackoverflow.com/questions/4461360/how-to-install-trusted-ca-certificate-on-android-device

or on this:

http://wiki.cacert.org/FAQ/ImportRootCert

Or, in your case,  you can differentiate users by, for example, by
network and pass wifi users to splice rule. Much approaches exists.
>
>
>>
>> Or do I have to move to a scenario with a defined proxy in another
>> server, and automatically established in clients with DHCP ???
>>
>
> Explicit proxy is definitely better for HTTP than interception proxy.
> That is true regardless of what else is going on. So worth doing *if*
> you can.
Oh, really? You have forgotten about beatiful 252 option in DHCP, about
WCCP interception, and such other good things. In other world,
transparent interception requires just more experienced sysadmin. This
simple requires more experience with squid, LAN equipement, and a bit
more work. So, "definitely better" is very discussable statement.
>
> That said, it is also unlikely to help much with the problem you are
> facing. Perhapse a small gain for clients not sending TLS SNI values -
> otherwise no change can be expected.
>
> Amos
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-- 
*
* C++20 : Bug to the future *
*

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

Re: [squid-users] Transparent proxy for WiFi users

[Amos Jeffries]

On 03/01/18 02:48, Roberto Carna wrote:

Dear, I've setup a Squid transparent proxy + Squidgard on pfSEnse 2.4
in order to filter HTTP and HTTPS web content for different types of
WiFi clients on my company:

- Android (different versions)
- Notebooks Windows 7/10
- Iphone
- Etc.

In some cases, depending on the device Operating System, some apps
experiment problems, for example Facebook and some others.


The main cause of these problems is that when the same vendor is 
authoring both the server software and the client "app" (or client 
device OS). They can (and often do) hard-code TLS certificate checks 
into their client code to detect and immediately fail in the presence of 
MITM in the encryption.


Following that, SSL-Bump is still very much an ongoing project. 
Selecting even a slightly older Squid version can lead to TLS features 
not being supported. So when problems occur the best option is still to 
upgrade to the very latest release before debugging further - today that 
would be squid-4.0.22 beta.





Which is the best solution in order to setup a TRANSPARENT proxy
service in a heterogeneous scenario with diferenbt types of devices,
and running in the best mode with the minimum number of problems???


The _only_ solution is not to decrypt such traffic (the splice action). 
How you determine which traffic is having such special trust given to it 
is up to you. The TLS SNI is provided by the peek action at SSL-Bump step 1.





Or do I have to move to a scenario with a defined proxy in another
server, and automatically established in clients with DHCP ???



Explicit proxy is definitely better for HTTP than interception proxy. 
That is true regardless of what else is going on. So worth doing *if* 
you can.


That said, it is also unlikely to help much with the problem you are 
facing. Perhapse a small gain for clients not sending TLS SNI values - 
otherwise no change can be expected.


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

Re: [squid-users] Transparent Proxy in AWS

[Jason Haar]

On Fri, Dec 2, 2016 at 6:27 AM, klops  wrote:

> Does this mean the squid box has to be the overall gateway for the internal
> network for transparrancy to work?
>
> The reason the proposed setup the way it is is because AWS VPC  service has
> a service based NAT gateway which we have not low level control over and it
> is the default gateway. We want to only route http/https traffic over to
> squid and the rest via their NAT gateway
>

Couldn't you configure those VPC networks so that the AWS default route is
dead by blocking all outbound (ie of no useable value to the EC2 hosts) and
tell the EC2 hosts owners to change their boot scripts to delete the
default gateway and replace it with your squid router? (which does have
Internet access). That way you are "regaining control" of your network, and
EC2 owners are "motivated" to Do The Right Thing :-)

Then there'd be no need for iptable tricks on the clients. Also means you
could apply this to Windows EC2 systems too

I'm not an AWS guru so I have no idea if that works. I'm assuming a VPC is
like a VLAN

-- 
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Transparent Proxy in AWS

[Amos Jeffries]

On 2/12/2016 6:27 a.m., klops wrote:
> Does this mean the squid box has to be the overall gateway for the internal
> network for transparrancy to work?

That is just one option. The other two are routing or tunnel, as I
mentioned in the second sentence.

> 
> The reason the proposed setup the way it is is because AWS VPC  service has
> a service based NAT gateway which we have not low level control over and it
> is the default gateway. We want to only route http/https traffic over to
> squid and the rest via their NAT gateway

NAT is a destructive process. DNAT erases the clients original
destination-IP and the only way around that requires that DNAT to happen
on the same machine as Squid.

If you cannot do that, then you cannot use intercept or tproxy modes on
this Squid.

Amos

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

Re: [squid-users] Transparent Proxy in AWS

[klops]

Does this mean the squid box has to be the overall gateway for the internal
network for transparrancy to work?

The reason the proposed setup the way it is is because AWS VPC  service has
a service based NAT gateway which we have not low level control over and it
is the default gateway. We want to only route http/https traffic over to
squid and the rest via their NAT gateway

Thanks in advance for the followup 



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Transparent-Proxy-in-AWS-tp4680691p4680712.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Transparent Proxy in AWS

[Amos Jeffries]

On 29/11/2016 10:33 a.m., kevin2345 wrote:

Hello, new to squid here.  I'm trying to setup a transparent proxy with squid
for my internal hosts to reach outbound destinations.  We are hosted in AWS
with a VPC setup and multiple subnets.  The squid host is in a "public"
subnet that has outbound access, while the other subnets are "private" with
access to the hosts in the public subnet.  The end goal is to have all
outbound traffic in the VPC routed to the squid host before going to the
internet.  By doing this, we'll have a central "choke point" to manage in


Hint: In networking that is called a _gateway_ or router.


terms of access/auditing.  We want to accomplish this with iptables rules on
the clients (eventually managed with config management) that direct outbound
traffic (http/https for example) to the squid host.


So long as you dont use DNAT or REDIRECT. Any form of routing or tunnel, 
or setting the clients gateway to be the Squid machine should be okay.



I've tried setting up the squid host with Ubuntu 14.04 and squid 3.3.8.  I
am testing http access with a curl to ifconfig.co (which would return the
external IP address),


 ... but apparently does not.


  but I'm running into 403/access denied errors.  See
below for log excerpts and the config files.  "172.18.128.58" is my squid
proxy host and "172.18.145.88" is my test client.


Not any old "403 Access Denied" but Forwarding Loop denials.



squid.conf:

http_port 3128 intercept
http_port 80

acl localnet src 172.18.0.0/16
acl localhost src 127.0.0.1

acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 443 # https
acl CONNECT method CONNECT
follow_x_forwarded_for allow localhost

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localnet
http_access allow localhost
http_access allow all

cache_dir ufs /var/spool/squid3 100 16 256
coredump_dir /var/spool/squid3

visible_hostname squidhost

debug_options ALL,1 33,2 28,9



squid logs:

==> /var/log/squid3/cache.log <==
2016/11/28 19:26:45.119| WARNING: Forwarding loop detected for:
GET / HTTP/1.1
User-Agent: curl/7.35.0
Accept: */*
Via: 1.1 squidhost (squid/3.3.8)
X-Forwarded-For: 172.18.145.88
Cache-Control: max-age=259200
Connection: keep-alive
Host: ifconfig.co





==> /var/log/squid3/access.log <==
1480361205.120  0 172.18.128.58 TCP_MISS/403 3629 GET
http://ifconfig.co/ - HIER_NONE/- text/html
1480361205.120  1 172.18.145.88 TCP_MISS/403 3728 GET
http://ifconfig.co/ - HIER_DIRECT/172.18.128.58 text/html

==> /var/log/squid3/cache.log <==

==> /var/log/squid3/access.log <==

==> /var/log/squid3/cache.log <==
2016/11/28 19:26:45.123| client_side.cc(777) swanSong:
local=172.18.128.58:3128 remote=172.18.145.88:36030 flags=33



iptables rules on test client:

ubuntu@ip-172-18-145-88:~$ sudo iptables -t nat -nvL
Chain PREROUTING (policy ACCEPT 7 packets, 448 bytes)
  pkts bytes target prot opt in out source
destination

Chain INPUT (policy ACCEPT 7 packets, 448 bytes)
  pkts bytes target prot opt in out source
destination

Chain OUTPUT (policy ACCEPT 624 packets, 125K bytes)
  pkts bytes target prot opt in out source
destination
   442 26520 DNAT   tcp  --  *  *   0.0.0.0/0
0.0.0.0/0tcp dpt:80 to:172.18.128.58:3128


The DNAT on the client informs Squid that the real IP of the server is 
172.18.128.58. Squid will send the request upstream to that IP ...


Please follow the Config Example 
, in 
particular the first NOTE about where the configuration needs to be 
done. Hint: not on the client.


Amos

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

Re: [squid-users] Transparent Proxy

[Amos Jeffries]

On 8/09/2016 11:54 p.m., John Sayce wrote:
> Yeah, that was the key.  I was expecting my firewall to be doing NAT but 
> destination NAT rather than source NAT.  I hadn't realised this was 
> completely wrong.  
> 
> Got it working now.

Source-NAT is fine and sometimes needed to translate between subnets.
But Destination-NAT before the TCP packets reach the Squid machine kills
the MITM being done by proxy machine.

Amos

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

Re: [squid-users] Transparent Proxy

[John Sayce]

Yeah, that was the key.  I was expecting my firewall to be doing NAT but 
destination NAT rather than source NAT.  I hadn't realised this was completely 
wrong.  

Got it working now.

Thanks


-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of Antony Stone
Sent: 08 September 2016 10:00
To: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Transparent Proxy

On Thursday 08 September 2016 at 10:44:12, John Sayce wrote:

> After I wrote this I realised it should be changing the mac not the 
> ip, which is not what’s happeneing.  I think it's my firewall 
> configuration that's wrong.

In that case your firewall is doing NAT instead of policy routing.

Regards,


Antony.

> -Original Message-
> From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] 
> On Behalf Of Antony Stone Sent: 08 September 2016 09:36
> To: squid-users@lists.squid-cache.org
> Subject: Re: [squid-users] Transparent Proxy
> 
> On Thursday 08 September 2016 at 10:12:48, John Sayce wrote:
> > For testing purposes I've reduced it to the following:
> > 
> > http_port 3128 intercept
> > #dns_v4_first on
> > dns_nameservers 10.8.2.3 194.168.4.100 10.8.2.2 8.8.8.8 acl wifi src
> > 10.8.14.0/24 acl all src all http_access allow all 
> > maximum_object_size
> > 1 GB minimum_object_size 0 KB maximum_object_size_in_memory 4 MB 
> > cache_mem 1700 MB cache_dir aufs /var/cache/squid 4 32 512 
> > coredump_dir /var/cache/squid access_log /var/log/squid/access.log 
> > squid cache_log /var/log/squid/cache.log
> > refresh_pattern ^ftp:   144020% 10080
> > refresh_pattern ^gopher:14400%  1440
> > refresh_pattern -i (/cgi-bin/|\?) 0 0%  0
> > refresh_pattern .   0   20% 4320
> > cache_effective_user asd
> > cache_effective_group asd
> > cache_mgr jsa...@asdlighting.com
> > forwarded_for off
> > 
> > The version is 3.5.12
> > 
> > Okay.  Sorry, to clarify with a specific example.
> 
> Don't apologise - specific examples are good, because it makes sure 
> we're both talking about the same thing (and sometimes, as below, 
> reveals little details about the network arrangement which weren't previously 
> clear).
> 
> > Lets say I'm contacting http://1.1.1.1/ then the ack packet starts 
> > off with the client with ip address 10.8.14.9
> 
> So, source IP = 10.8.14.9 : destination IP = 1.1.11
> 
> > in subnet 10.8.14.9/24 with default gateway 10.8.14.1.
> > It's routed through my core switch to my my firewall with ip 10.8.1.1.
> 
> So that's a router, not just a switch?  It has one interface 10.8.14.1 
> on subnet 10.8.14.0/24 and another interface on (presumably) 
> 10.8.1.0/24 pointing at 10.8.1.1 as the next-hop route towards 1.1.1.1
> 
> > My firewall recognises that the packet has a destination port 80 and 
> > is in subnet 10.8.14.0/24
> 
> The source address is in that subnet, yes.
> 
> > and changes the destination address to be that of my proxy server 
> > 10.8.2.11.
> 
> No - see below.
> 
> > So now the ack packet has source 10.8.14.9 and destination 10.8.2.11.
> 
> No, it doesn't.  When a packet goes via a router, its destination IP 
> address is not changed to the address of the next-hop router 
> (otherwise things would never work across the Internet).
> 
> It's only the destination MAC address in the encapsulating ethernet 
> frame which gets changed to that of the next-hop router.  The source 
> and destination IP addresses inside are not touched.
> 
> > How does iptables know to reply to my client 10.8.14.9 with source 
> > address 1.1.1.1?  Does iptables know to read the header?
> 
> TCP header, yes.
> 
> HTTP header, no.
> 
> Just think about the very first link between the client and its 
> default
> gateway:
> 
> Packet with source address = 10.8.14.9, destinatoin address = 1.1.1.1
> 
> How does that packet get to the default router 10.8.14.1?  Its 
> destination IP is 1.1.1.1, so that doesn't help.
> 
> It's because the destination MAC address in the ethernet frame 
> containing that IP packet is the MAC address of 10.8.14.1.
> 
> A few minutes playing around with wireshark on your network could be 
> quite enlightening :)
> 
> 
> 
> Regards,
> 
> 
> Antony.

--
"Reports that say that something hasn't happened are always interesting to me, 
because as we know, there are known knowns; there are things we know we know. 
We also know there are known unknowns; that is to say we k

Re: [squid-users] Transparent Proxy

[Antony Stone]

On Thursday 08 September 2016 at 10:44:12, John Sayce wrote:

> After I wrote this I realised it should be changing the mac not the ip,
> which is not what’s happeneing.  I think it's my firewall configuration
> that's wrong.

In that case your firewall is doing NAT instead of policy routing.

Regards,


Antony.

> -Original Message-
> From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On
> Behalf Of Antony Stone Sent: 08 September 2016 09:36
> To: squid-users@lists.squid-cache.org
> Subject: Re: [squid-users] Transparent Proxy
> 
> On Thursday 08 September 2016 at 10:12:48, John Sayce wrote:
> > For testing purposes I've reduced it to the following:
> > 
> > http_port 3128 intercept
> > #dns_v4_first on
> > dns_nameservers 10.8.2.3 194.168.4.100 10.8.2.2 8.8.8.8 acl wifi src
> > 10.8.14.0/24 acl all src all http_access allow all maximum_object_size
> > 1 GB minimum_object_size 0 KB maximum_object_size_in_memory 4 MB
> > cache_mem 1700 MB cache_dir aufs /var/cache/squid 4 32 512
> > coredump_dir /var/cache/squid access_log /var/log/squid/access.log
> > squid cache_log /var/log/squid/cache.log
> > refresh_pattern ^ftp:   144020% 10080
> > refresh_pattern ^gopher:14400%  1440
> > refresh_pattern -i (/cgi-bin/|\?) 0 0%  0
> > refresh_pattern .   0   20% 4320
> > cache_effective_user asd
> > cache_effective_group asd
> > cache_mgr jsa...@asdlighting.com
> > forwarded_for off
> > 
> > The version is 3.5.12
> > 
> > Okay.  Sorry, to clarify with a specific example.
> 
> Don't apologise - specific examples are good, because it makes sure we're
> both talking about the same thing (and sometimes, as below, reveals little
> details about the network arrangement which weren't previously clear).
> 
> > Lets say I'm contacting http://1.1.1.1/ then the ack packet starts off
> > with the client with ip address 10.8.14.9
> 
> So, source IP = 10.8.14.9 : destination IP = 1.1.11
> 
> > in subnet 10.8.14.9/24 with default gateway 10.8.14.1.
> > It's routed through my core switch to my my firewall with ip 10.8.1.1.
> 
> So that's a router, not just a switch?  It has one interface 10.8.14.1 on
> subnet 10.8.14.0/24 and another interface on (presumably) 10.8.1.0/24
> pointing at 10.8.1.1 as the next-hop route towards 1.1.1.1
> 
> > My firewall recognises that the packet has a destination port 80 and
> > is in subnet 10.8.14.0/24
> 
> The source address is in that subnet, yes.
> 
> > and changes the destination address to be that of my proxy server
> > 10.8.2.11.
> 
> No - see below.
> 
> > So now the ack packet has source 10.8.14.9 and destination 10.8.2.11.
> 
> No, it doesn't.  When a packet goes via a router, its destination IP
> address is not changed to the address of the next-hop router (otherwise
> things would never work across the Internet).
> 
> It's only the destination MAC address in the encapsulating ethernet frame
> which gets changed to that of the next-hop router.  The source and
> destination IP addresses inside are not touched.
> 
> > How does iptables know to reply to my client 10.8.14.9 with source
> > address 1.1.1.1?  Does iptables know to read the header?
> 
> TCP header, yes.
> 
> HTTP header, no.
> 
> Just think about the very first link between the client and its default
> gateway:
> 
> Packet with source address = 10.8.14.9, destinatoin address = 1.1.1.1
> 
> How does that packet get to the default router 10.8.14.1?  Its destination
> IP is 1.1.1.1, so that doesn't help.
> 
> It's because the destination MAC address in the ethernet frame containing
> that IP packet is the MAC address of 10.8.14.1.
> 
> A few minutes playing around with wireshark on your network could be quite
> enlightening :)
> 
> 
> 
> Regards,
> 
> 
> Antony.

-- 
"Reports that say that something hasn't happened are always interesting to me, 
because as we know, there are known knowns; there are things we know we know. 
We also know there are known unknowns; that is to say we know there are some 
things we do not know. But there are also unknown unknowns - the ones we don't 
know we don't know."

 - Donald Rumsfeld, US Secretary of Defence

   Please reply to the list;
 please *don't* CC me.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Transparent Proxy

[John Sayce]

After I wrote this I realised it should be changing the mac not the ip, which 
is not what’s happeneing.  I think it's my firewall configuration that's wrong.

Thanks



-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of Antony Stone
Sent: 08 September 2016 09:36
To: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Transparent Proxy

On Thursday 08 September 2016 at 10:12:48, John Sayce wrote:

> For testing purposes I've reduced it to the following:
> 
> http_port 3128 intercept
> #dns_v4_first on
> dns_nameservers 10.8.2.3 194.168.4.100 10.8.2.2 8.8.8.8 acl wifi src 
> 10.8.14.0/24 acl all src all http_access allow all maximum_object_size 
> 1 GB minimum_object_size 0 KB maximum_object_size_in_memory 4 MB 
> cache_mem 1700 MB cache_dir aufs /var/cache/squid 4 32 512 
> coredump_dir /var/cache/squid access_log /var/log/squid/access.log 
> squid cache_log /var/log/squid/cache.log
> refresh_pattern ^ftp:   144020% 10080
> refresh_pattern ^gopher:14400%  1440
> refresh_pattern -i (/cgi-bin/|\?) 0 0%  0
> refresh_pattern .   0   20% 4320
> cache_effective_user asd
> cache_effective_group asd
> cache_mgr jsa...@asdlighting.com
> forwarded_for off
> 
> The version is 3.5.12
> 
> Okay.  Sorry, to clarify with a specific example.

Don't apologise - specific examples are good, because it makes sure we're both 
talking about the same thing (and sometimes, as below, reveals little details 
about the network arrangement which weren't previously clear).

> Lets say I'm contacting http://1.1.1.1/ then the ack packet starts off 
> with the client with ip address 10.8.14.9

So, source IP = 10.8.14.9 : destination IP = 1.1.11

> in subnet 10.8.14.9/24 with default gateway 10.8.14.1. 
> It's routed through my core switch to my my firewall with ip 10.8.1.1.

So that's a router, not just a switch?  It has one interface 10.8.14.1 on 
subnet 10.8.14.0/24 and another interface on (presumably) 10.8.1.0/24 pointing 
at 10.8.1.1 as the next-hop route towards 1.1.1.1

> My firewall recognises that the packet has a destination port 80 and 
> is in subnet 10.8.14.0/24

The source address is in that subnet, yes.

> and changes the destination address to be that of my proxy server 10.8.2.11.

No - see below.

> So now the ack packet has source 10.8.14.9 and destination 10.8.2.11.

No, it doesn't.  When a packet goes via a router, its destination IP address is 
not changed to the address of the next-hop router (otherwise things would never 
work across the Internet).

It's only the destination MAC address in the encapsulating ethernet frame which 
gets changed to that of the next-hop router.  The source and destination IP 
addresses inside are not touched.

> How does iptables know to reply to my client 10.8.14.9 with source 
> address 1.1.1.1?  Does iptables know to read the header?

TCP header, yes.

HTTP header, no.

Just think about the very first link between the client and its default
gateway:

Packet with source address = 10.8.14.9, destinatoin address = 1.1.1.1

How does that packet get to the default router 10.8.14.1?  Its destination IP 
is 1.1.1.1, so that doesn't help.

It's because the destination MAC address in the ethernet frame containing that 
IP packet is the MAC address of 10.8.14.1.

A few minutes playing around with wireshark on your network could be quite 
enlightening :)



Regards,


Antony.

-- 
I think broken pencils are pointless.

   Please reply to the list;
 please *don't* CC me.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://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] Transparent Proxy

[Antony Stone]

On Thursday 08 September 2016 at 10:12:48, John Sayce wrote:

> For testing purposes I've reduced it to the following:
> 
> http_port 3128 intercept
> #dns_v4_first on
> dns_nameservers 10.8.2.3 194.168.4.100 10.8.2.2 8.8.8.8
> acl wifi src 10.8.14.0/24
> acl all src all
> http_access allow all
> maximum_object_size 1 GB
> minimum_object_size 0 KB
> maximum_object_size_in_memory 4 MB
> cache_mem 1700 MB
> cache_dir aufs /var/cache/squid 4 32 512
> coredump_dir /var/cache/squid
> access_log /var/log/squid/access.log squid
> cache_log /var/log/squid/cache.log
> refresh_pattern ^ftp:   144020% 10080
> refresh_pattern ^gopher:14400%  1440
> refresh_pattern -i (/cgi-bin/|\?) 0 0%  0
> refresh_pattern .   0   20% 4320
> cache_effective_user asd
> cache_effective_group asd
> cache_mgr jsa...@asdlighting.com
> forwarded_for off
> 
> The version is 3.5.12
> 
> Okay.  Sorry, to clarify with a specific example.

Don't apologise - specific examples are good, because it makes sure we're both 
talking about the same thing (and sometimes, as below, reveals little details 
about the network arrangement which weren't previously clear).

> Lets say I'm contacting http://1.1.1.1/ then the ack packet starts off with
> the client with ip address 10.8.14.9

So, source IP = 10.8.14.9 : destination IP = 1.1.11

> in subnet 10.8.14.9/24 with default gateway 10.8.14.1. 
> It's routed through my core switch to my my firewall with ip 10.8.1.1.

So that's a router, not just a switch?  It has one interface 10.8.14.1 on 
subnet 10.8.14.0/24 and another interface on (presumably) 10.8.1.0/24 pointing 
at 10.8.1.1 as the next-hop route towards 1.1.1.1

> My firewall recognises that the packet has a destination port 80 and is in
> subnet 10.8.14.0/24

The source address is in that subnet, yes.

> and changes the destination address to be that of my proxy server 10.8.2.11.

No - see below.

> So now the ack packet has source 10.8.14.9 and destination 10.8.2.11.

No, it doesn't.  When a packet goes via a router, its destination IP address 
is not changed to the address of the next-hop router (otherwise things would 
never work across the Internet).

It's only the destination MAC address in the encapsulating ethernet frame 
which gets changed to that of the next-hop router.  The source and destination 
IP addresses inside are not touched.

> How does iptables know to reply to my client 10.8.14.9 with source address
> 1.1.1.1?  Does iptables know to read the header?

TCP header, yes.

HTTP header, no.

Just think about the very first link between the client and its default 
gateway:

Packet with source address = 10.8.14.9, destinatoin address = 1.1.1.1

How does that packet get to the default router 10.8.14.1?  Its destination IP 
is 1.1.1.1, so that doesn't help.

It's because the destination MAC address in the ethernet frame containing that 
IP packet is the MAC address of 10.8.14.1.

A few minutes playing around with wireshark on your network could be quite 
enlightening :)



Regards,


Antony.

-- 
I think broken pencils are pointless.

   Please reply to the list;
 please *don't* CC me.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Transparent Proxy

[John Sayce]

For testing purposes I've reduced it to the following:

http_port 3128 intercept
#dns_v4_first on
dns_nameservers 10.8.2.3 194.168.4.100 10.8.2.2 8.8.8.8
acl wifi src 10.8.14.0/24
acl all src all
http_access allow all
maximum_object_size 1 GB
minimum_object_size 0 KB
maximum_object_size_in_memory 4 MB
cache_mem 1700 MB
cache_dir aufs /var/cache/squid 4 32 512
coredump_dir /var/cache/squid
access_log /var/log/squid/access.log squid
cache_log /var/log/squid/cache.log
refresh_pattern ^ftp:   144020% 10080
refresh_pattern ^gopher:14400%  1440
refresh_pattern -i (/cgi-bin/|\?) 0 0%  0
refresh_pattern .   0   20% 4320
cache_effective_user asd
cache_effective_group asd
cache_mgr jsa...@asdlighting.com
forwarded_for off

The version is 3.5.12

Okay.  Sorry, to clarify with a specific example.  Lets say I'm contacting 
http://1.1.1.1/ then the ack packet starts off with the client with ip address 
10.8.14.9 in subnet 10.8.14.9/24 with default gateway 10.8.14.1.  It's routed 
through my core switch to my my firewall with ip 10.8.1.1.  My firewall 
recognises that the packet has a destination port 80 and is in subnet 
10.8.14.0/24 and changes the destination address to be that of my proxy server 
10.8.2.11.  So now the ack packet has source 10.8.14.9 and destination 
10.8.2.11.  How does iptables know to reply to my client 10.8.14.9 with source 
address 1.1.1.1?  Does iptables know to read the header?

Thanks


-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of Antony Stone
Sent: 07 September 2016 10:27
To: 'squid-users@lists.squid-cache.org'
Subject: Re: [squid-users] Transparent Proxy

On Wednesday 07 September 2016 at 10:51:49, John Sayce wrote:

> I believe so.  The specific command I used was:
> 
> iptables -t nat -A PREROUTING -i ens33 -p tcp --dport 80 -j REDIRECT 
> --to-port 3128
> 
> (For some reason my adapter is ens33, I have no idea why it's not eth0. 
> Squid is set to run on 3128.)

That looks okay, then.

> It's fair to say I have almost no experience with iptables.  Is it 
> iptables that should be doing the address translation?

Yes - the rule above tells the machine to take any packet addressed to port 80 
on any address and send it instead to the local machine (REDIRECT changes the 
destination address to 127.0.0.1, even though that's not obvious) and port 3128.

> when the packet is sent back to the client?

Correct.  IPtables' address translation rules are automatically symmetrical - 
when a packet gets translated in one direction, a record is kept that it was 
done, and then the reply packet is automatically reverse-translated when it 
comes back in the other direction.

This is true no matter whether packets are going *through* the IPtables machine 
(ie: it's acting as a router), or whether they're being processed *on* the 
IPtables machine (as in this case).

I think we need to know more about your squid setup.

Please tell us which version of squid you are using, and post here your 
squid.conf file without comments or blank lines.


Antony.

-- 
Software development can be quick, high quality, or low cost.

The customer gets to pick any two out of three.

   Please reply to the list;
 please *don't* CC me.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://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] Transparent Proxy

[Amos Jeffries]

On 7/09/2016 9:27 p.m., Antony Stone wrote:
> On Wednesday 07 September 2016 at 10:51:49, John Sayce wrote:
> 

FYI: Jon. Please be careful about yoru use of teh word "forward" and
"forwarding". Both NAT and routing  are methods of forwarding, but which
one is used at each particular step of the packets path through your
network from client to Squid matters A LOT.

Some routers offer "forwarding" options / settings, which actually NAT.
That will break MITM Squid installations which require routing only
outside the Squid machine.


>> I believe so.  The specific command I used was:
>>
>> iptables -t nat -A PREROUTING -i ens33 -p tcp --dport 80 -j REDIRECT
>> --to-port 3128
>>
>> (For some reason my adapter is ens33, I have no idea why it's not eth0. 
>> Squid is set to run on 3128.)
> 
> That looks okay, then.
> 
>> It's fair to say I have almost no experience with iptables.  Is it iptables
>> that should be doing the address translation?
> 
> Yes - the rule above tells the machine to take any packet addressed to port 
> 80 
> on any address and send it instead to the local machine (REDIRECT changes the 
> destination address to 127.0.0.1, even though that's not obvious) and port 
> 3128.

No it does not change the IP to localhost. It changes the address to the
machines primary IP. If that is localhost IP then something is wrong in
the machines network interface configuration - which may lead to trouble.


> 
>> when the packet is sent back to the client?
> 
> Correct.  IPtables' address translation rules are automatically symmetrical - 
> when a packet gets translated in one direction, a record is kept that it was 
> done, and then the reply packet is automatically reverse-translated when it 
> comes back in the other direction.
> 
> This is true no matter whether packets are going *through* the IPtables 
> machine (ie: it's acting as a router), or whether they're being processed 
> *on* 
> the IPtables machine (as in this case).
> 
> I think we need to know more about your squid setup.
> 
> Please tell us which version of squid you are using, and post here your 
> squid.conf file without comments or blank lines.
> 


Amos

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

Re: [squid-users] Transparent Proxy

[Antony Stone]

On Wednesday 07 September 2016 at 10:51:49, John Sayce wrote:

> I believe so.  The specific command I used was:
> 
> iptables -t nat -A PREROUTING -i ens33 -p tcp --dport 80 -j REDIRECT
> --to-port 3128
> 
> (For some reason my adapter is ens33, I have no idea why it's not eth0. 
> Squid is set to run on 3128.)

That looks okay, then.

> It's fair to say I have almost no experience with iptables.  Is it iptables
> that should be doing the address translation?

Yes - the rule above tells the machine to take any packet addressed to port 80 
on any address and send it instead to the local machine (REDIRECT changes the 
destination address to 127.0.0.1, even though that's not obvious) and port 
3128.

> when the packet is sent back to the client?

Correct.  IPtables' address translation rules are automatically symmetrical - 
when a packet gets translated in one direction, a record is kept that it was 
done, and then the reply packet is automatically reverse-translated when it 
comes back in the other direction.

This is true no matter whether packets are going *through* the IPtables 
machine (ie: it's acting as a router), or whether they're being processed *on* 
the IPtables machine (as in this case).

I think we need to know more about your squid setup.

Please tell us which version of squid you are using, and post here your 
squid.conf file without comments or blank lines.


Antony.

-- 
Software development can be quick, high quality, or low cost.

The customer gets to pick any two out of three.

   Please reply to the list;
 please *don't* CC me.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Transparent Proxy

[John Sayce]

I believe so.  The specific command I used was:

iptables -t nat -A PREROUTING -i ens33 -p tcp --dport 80 -j REDIRECT --to-port 
3128

(For some reason my adapter is ens33, I have no idea why it's not eth0.  Squid 
is set to run on 3128.)

And after running this command port 80 now shows as being open with nmap.

And the output from iptables -t nat -L

Chain PREROUTING (policy ACCEPT)
target prot opt source   destination
REDIRECT   tcp  --  anywhere anywhere tcp dpt:http 
redir ports 3128

Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source   destination


It's fair to say I have almost no experience with iptables.  Is it iptables 
that should be doing the address translation? when the packet is sent back to 
the client? 



-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of Antony Stone
Sent: 07 September 2016 09:28
To: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Transparent Proxy

On Wednesday 07 September 2016 at 10:23:02, John Sayce wrote:

> I'm trying to set up a transparent proxy but I'm fairly sure I'm 
> missing something.
> 
> I've followed the instructions on the juniper website along with a 
> couple of other blogs as per:
> https://damn.technology/using-squid-juniper-pbr-transparent-proxy

You *have* applied the iptables rule on the machine running squid as described 
on that page, yes?

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port
3128


Antony.

-- 
This email was created using 100% recycled electrons.

   Please reply to the list;
 please *don't* CC me.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://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] Transparent Proxy

[Antony Stone]

On Wednesday 07 September 2016 at 10:23:02, John Sayce wrote:

> I'm trying to set up a transparent proxy but I'm fairly sure I'm missing
> something.
> 
> I've followed the instructions on the juniper website along with a couple
> of other blogs as per:
> https://damn.technology/using-squid-juniper-pbr-transparent-proxy

You *have* applied the iptables rule on the machine running squid as described 
on that page, yes?

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 
3128


Antony.

-- 
This email was created using 100% recycled electrons.

   Please reply to the list;
 please *don't* CC me.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Transparent Proxy on OSX Yosemite

[Shively, Gregory]

> -Original Message-
> From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf
> Of Amos Jeffries
> Sent: Thursday, September 1, 2016 11:05 AM
> To: squid-users@lists.squid-cache.org
> Subject: [EXTERNAL] Re: [squid-users] Transparent Proxy on OSX Yosemite
> 
> On 1/09/2016 5:59 a.m., Shively, Gregory wrote:
> >> On 31/08/2016 11:19 a.m., Shively, Gregory wrote:
> >
> >>> I'm attempting to get a squid working as a transparent proxy on OSX
> >
> >>> Yosemite. Every attempt ended with a "Forward loop detected". I
> >
> >>> initially started with the version from homebrew and moved to just
> >
> >>> compiling myself to see if I could figure out what was going on.
> >
> >>> Being new to both pf network and squid, it might be something that I
> >
> >>> have configured wrong. I configured pf similar to:
> >
> >>>
> >
> >>> nat on $ext_if proto {udp, tcp} from $int_if:network to any port
> >>> domain -> ($ext_if)
> >
> >>> rdr pass on $int_if proto tcp from $int_if:network to any port
> >
> >>> {http, https} -> 127.0.0.1 port 3129
> >
> >>>
> >
> >>> And my squid.conf for my testing is basically:
> >
> >>>
> >
> >>> http_port 3128
> >
> >>> http_port 3129 intercept
> >
> >>> http_access allow all
> >
> >>>
> >
> >
> >
> >>> I'm not sure if this is more appropriate on this mailing list or the
> >
> >>> developer mailing list (hoping it is just something I'm doing
> >>> wrong).
> >
> >>> The squid that I'm using doesn't have -with-nat-devpf enabled; it
> >
> >>> fails to compile with that option. I'm wondering if the
> >>> getsockname()
> >
> >>> as per comment for PFIntercept (of the !_USE_NAT_DEVPF) in
> >
> >>> src/ip/Intercept.cc, on OSX is not returning the pre-rdr address and
> >
> >>> causing the forward loop.
> >
> >
> >
> >> Your access.log can show that. It shows up as the server the
> >> transaction is being sent to being port 3128/3129 on 127.0.0.1 or
> >> another IP assigned to the Squid machine.
> >
> >
> >
> > It looks like I get 2 associated TCP_MISS entries in the access.log,
> 
> saying what? *exact details* are important for debugging these types of issue.
> 

I apologize - my Mac where I'm testing was on a different network where I 
wasn't able to send email and couldn't get access to copy and paste. I now have 
access to the log entries:

1472664782.393  0 127.0.0.1 TCP_MISS/403 4417 GET 
http://google.com/ - HIER_NONE/- text/html
1472664782.394  6 192.168.100.2 TCP_MISS/403 4487 GET 
http://google.com/ - ORIGINAL_DST/127.0.0.1 text/html
1472664782.468  0 192.168.100.2 TCP_MEM_HIT/200 13035 GET 
http://osx-mdslfd56-u:3128/squid-internal-static/icons/SN.png - HIER_NONE/- 
image/png
1472664784.921  0 192.168.100.2 TAG_NONE/400 4401 NONE 
error:invalid-request - HIER_NONE/- text/html


> > followed by entries that looks like they are associated with the
> > access denied error screen. All generate the forwarding loop warning
> > when running squid in debug.  I also had the pf logging and see the
> > rdr getting redirected, plus had started netcat listening on 3129
> > prior to starting squid and saw the HTTP request come in.
> >
> 
> The netcat test tells nothing you dont already know. A forwarding loop by
> definition is the request arriving into Squid, then going out and coming 
> right back
> a second time (thus 2+ access.log entries).
> 
> netcat test only shows the first arrival, which is of course normal. It also 
> does
> not perform the NAT lookup and de-mangling Squid does - so wont show if that
> is part of the problem or not.
> 
> 

Thanks for the explanation - from observation, that is what I was guessing on 
how it was working. But hearing it helps.

> >> * check the PF version in your MacOS. If it derives from OpenBSD
> >> 4.8 or later then the .dev.pf is not relevant - rdr/divert-to failure
> >> is then a bug somewhere AFAIK.
> >
> >
> >
> > I tried using both the internal and external interface IP addresses on
> > the rdr rule. Both ended in the same forward loop. And it doesn't look
> > like, at least Yosemite, has the option to use the divert-to in the
> > firewall rules. I can't seem to find the refere

Re: [squid-users] Transparent Proxy on OSX Yosemite

[Amos Jeffries]

On 1/09/2016 5:59 a.m., Shively, Gregory wrote:
>> On 31/08/2016 11:19 a.m., Shively, Gregory wrote:
> 
>>> I'm attempting to get a squid working as a transparent proxy on
>>> OSX
> 
>>> Yosemite. Every attempt ended with a "Forward loop detected". I
> 
>>> initially started with the version from homebrew and moved to
>>> just
> 
>>> compiling myself to see if I could figure out what was going on.
> 
>>> Being new to both pf network and squid, it might be something
>>> that I
> 
>>> have configured wrong. I configured pf similar to:
> 
>>> 
> 
>>> nat on $ext_if proto {udp, tcp} from $int_if:network to any port
>>> domain -> ($ext_if)
> 
>>> rdr pass on $int_if proto tcp from $int_if:network to any port
> 
>>> {http, https} -> 127.0.0.1 port 3129
> 
>>> 
> 
>>> And my squid.conf for my testing is basically:
> 
>>> 
> 
>>> http_port 3128
> 
>>> http_port 3129 intercept
> 
>>> http_access allow all
> 
>>> 
> 
> 
> 
>>> I'm not sure if this is more appropriate on this mailing list or
>>> the
> 
>>> developer mailing list (hoping it is just something I'm doing
>>> wrong).
> 
>>> The squid that I'm using doesn't have -with-nat-devpf enabled;
>>> it
> 
>>> fails to compile with that option. I'm wondering if the
>>> getsockname()
> 
>>> as per comment for PFIntercept (of the !_USE_NAT_DEVPF) in
> 
>>> src/ip/Intercept.cc, on OSX is not returning the pre-rdr address
>>> and
> 
>>> causing the forward loop.
> 
> 
> 
>> Your access.log can show that. It shows up as the server the
>> transaction is being sent to being port 3128/3129 on 127.0.0.1 or
>> another IP assigned to the Squid machine.
> 
> 
> 
> It looks like I get 2 associated TCP_MISS entries in the access.log,

saying what? *exact details* are important for debugging these types of
issue.

> followed by entries that looks like they are associated with the
> access denied error screen. All generate the forwarding loop warning
> when running squid in debug.  I also had the pf logging and see the
> rdr getting redirected, plus had started netcat listening on 3129
> prior to starting squid and saw the HTTP request come in.
> 

The netcat test tells nothing you dont already know. A forwarding loop
by definition is the request arriving into Squid, then going out and
coming right back a second time (thus 2+ access.log entries).

netcat test only shows the first arrival, which is of course normal. It
also does not perform the NAT lookup and de-mangling Squid does - so
wont show if that is part of the problem or not.


>> * check the PF version in your MacOS. If it derives from OpenBSD
>> 4.8 or later then the .dev.pf is not relevant - rdr/divert-to
>> failure is then a bug somewhere AFAIK.
> 
> 
> 
> I tried using both the internal and external interface IP addresses
> on the rdr rule. Both ended in the same forward loop. And it doesn't
> look like, at least Yosemite, has the option to use the divert-to in
> the firewall rules. I can't seem to find the reference, but I think
> that the pf in OSX is based around OpenBSD 4.4 or 4.5, but don't hold
> me to it. I'm guessing that is the reason that the divert-to is not
> available. I can look at an El Capt machine, but don't currently have
> access.
> 
> 
> 
> Thanks for the help on getting this setup. I had put some code in the
> PfInterception method to replace the "local" address that I pulled
> from running the pfctl -s state command and it did change the
> results. But I'm thinking that I might have gotten the host or port
> in the "address" object incorrectly - it didn't seem to work and
> further connections just errored out. When I get a change will take a
> more detailed look and verify I'm getting the addresses in the
> correct form.

Okay. I'm thinking its not misconfiguration then and since it seems to
be a Mac-specific PF based on the old /vdev/pf logic you are going down
the right path.

If you can get it working I will take the patch. Wrap the Mac-specific
new bits in " #if _SQUID_APPLE_ " and the missing header include line
with " #if !_SQUID_APPLE_ ".

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

Re: [squid-users] Transparent Proxy on OSX Yosemite

[Shively, Gregory]

> On 31/08/2016 11:19 a.m., Shively, Gregory wrote:

> > I'm attempting to get a squid working as a transparent proxy on OSX

> > Yosemite. Every attempt ended with a "Forward loop detected". I

> > initially started with the version from homebrew and moved to just

> > compiling myself to see if I could figure out what was going on.

> > Being new to both pf network and squid, it might be something that I

> > have configured wrong. I configured pf similar to:

> >

> >nat on $ext_if proto {udp, tcp} from $int_if:network to any port domain 
> > -> ($ext_if)

> >rdr pass on $int_if proto tcp from $int_if:network to any port

> > {http, https} -> 127.0.0.1 port 3129

> >

> > And my squid.conf for my testing is basically:

> >

> > http_port 3128

> > http_port 3129 intercept

> > http_access allow all

> >



> > I'm not sure if this is more appropriate on this mailing list or the

> > developer mailing list (hoping it is just something I'm doing wrong).

> > The squid that I'm using doesn't have -with-nat-devpf enabled; it

> > fails to compile with that option. I'm wondering if the getsockname()

> > as per comment for PFIntercept (of the !_USE_NAT_DEVPF) in

> > src/ip/Intercept.cc, on OSX is not returning the pre-rdr address and

> > causing the forward loop.



> Your access.log can show that. It shows up as the server the transaction is 
> being sent to being port 3128/3129 on 127.0.0.1 or another IP assigned to the 
> Squid machine.



It looks like I get 2 associated TCP_MISS entries in the access.log, followed 
by entries that looks like they are associated with the access denied error 
screen. All generate the forwarding loop warning when running squid in debug.  
I also had the pf logging and see the rdr getting redirected, plus had started 
netcat listening on 3129 prior to starting squid and saw the HTTP request come 
in.



> >

> > As mentioned, the -with-nat-devpf fails to compile on OSX due to a

> > missing header file. And from looking it sounds like the header is for

> > the ioctl() on /dev/pf, which doesn't seem to be public API on OSX. So

> > I'm trying to determine if my issue is due to a misconfiguration - or

> > is this portion of the code not working with OSX.



> It has been a long time since anyone using MacOS has provided any particular 
> feedback about Squid behaviour on MacOS. So it could be just bugs when 
> running on MacOS.





> > I looked at the code for mitmproxy, and it seems like they require a

> > sudoers entry to run "pfctl -s state" and parse the state.

> > Would something like that need to be added to squid to support

> > transparent proxy on OSX. I had started to put some code together like

> > mitmproxy, but thought better check if I didn't get something

> > configured correctly.



> Squid (when built with the /dev/pf support) master process which is run as 
> root [you are running Squid from the root account right?] should be 
> preserving its permission to access the device before it drops down to low 
> privilege levels for handling the network traffic.



Yeah - I'm running the squid process as root; that is partially what headed me 
down the road with the /dev/pf - the permissions had changed after a reboot of 
the Mac and I started getting curious on why squid didn't give me a permission 
warning in the same way that mitmproxy was. And from the code, at least in the 
portion of the code I was looking, since I didn't have the -use-devpf it 
doesn't seem to open the dev file.



> Some other troubleshooting things to try:



> * using the machines public IP addres instead of 127.0.0.1. There are 
> hardware or driver level restrictions on locahost addresses that often 
> prohibit that type of NAT.



> * using a divert-to rule instead of rdr. If your PF firewall accepts that and 
> the 'tproxy' option in squid.conf works then the /dev/pf is not relevant. rdr 
> sometimes does not work when divert-to is fine.



> * check the PF version in your MacOS. If it derives from OpenBSD 4.8 or later 
> then the .dev.pf is not relevant - rdr/divert-to failure is then a bug 
> somewhere AFAIK.



I tried using both the internal and external interface IP addresses on the rdr 
rule. Both ended in the same forward loop. And it doesn't look like, at least 
Yosemite, has the option to use the divert-to in the firewall rules. I can't 
seem to find the reference, but I think that the pf in OSX is based around 
OpenBSD 4.4 or 4.5, but don't hold me to it. I'm guessing that is the reason 
that the divert-to is not available. I can look at an El Capt machine, but 
don't currently have access.



Thanks for the help on getting this setup. I had put some code in the 
PfInterception method to replace the "local" address that I pulled from running 
the pfctl -s state command and it did change the results. But I'm thinking that 
I might have gotten the host or port in the "address" object incorrectly - it 
didn't seem to work and further connections just errored ou

Re: [squid-users] Transparent Proxy on OSX Yosemite

[Amos Jeffries]

On 31/08/2016 11:19 a.m., Shively, Gregory wrote:
> I'm attempting to get a squid working as a transparent proxy on OSX
> Yosemite. Every attempt ended with a "Forward loop detected". I
> initially started with the version from homebrew and moved to just
> compiling myself to see if I could figure out what was going on.
> Being new to both pf network and squid, it might be something that I
> have configured wrong. I configured pf similar to:
> 
>nat on $ext_if proto {udp, tcp} from $int_if:network to any port domain -> 
> ($ext_if)
>rdr pass on $int_if proto tcp from $int_if:network to any port {http, 
> https} -> 127.0.0.1 port 3129
> 
> And my squid.conf for my testing is basically:
> 
> http_port 3128
> http_port 3129 intercept
> http_access allow all
> 

> I'm not sure if this is more appropriate on this mailing list or the
> developer mailing list (hoping it is just something I'm doing wrong).
> The squid that I'm using doesn't have -with-nat-devpf enabled; it
> fails to compile with that option. I'm wondering if the getsockname()
> as per comment for PFIntercept (of the !_USE_NAT_DEVPF) in
> src/ip/Intercept.cc, on OSX is not returning the pre-rdr address and
> causing the forward loop.

Your access.log can show that. It shows up as the server the transaction
is being sent to being port 3128/3129 on 127.0.0.1 or another IP
assigned to the Squid machine.

> 
> As mentioned, the -with-nat-devpf fails to compile on OSX due to a
> missing header file. And from looking it sounds like the header is
> for the ioctl() on /dev/pf, which doesn't seem to be public API on
> OSX. So I'm trying to determine if my issue is due to a
> misconfiguration - or is this portion of the code not working with
> OSX.

It has been a long time since anyone using MacOS has provided any
particular feedback about Squid behaviour on MacOS. So it could be just
bugs when running on MacOS.


> I looked at the code for mitmproxy, and it seems like they
> require a sudoers entry to run "pfctl -s state" and parse the state.
> Would something like that need to be added to squid to support
> transparent proxy on OSX. I had started to put some code together
> like mitmproxy, but thought better check if I didn't get something
> configured correctly.

Squid (when built with the /dev/pf support) master process which is run
as root [you are running Squid from the root account right?] should be
preserving its permission to access the device before it drops down to
low privilege levels for handling the network traffic.

Some other troubleshooting things to try:

* using the machines public IP addres instead of 127.0.0.1. There are
hardware or driver level restrictions on locahost addresses that often
prohibit that type of NAT.

* using a divert-to rule instead of rdr. If your PF firewall accepts
that and the 'tproxy' option in squid.conf works then the /dev/pf is not
relevant. rdr sometimes does not work when divert-to is fine.

* check the PF version in your MacOS. If it derives from OpenBSD 4.8 or
later then the .dev.pf is not relevant - rdr/divert-to failure is then a
bug somewhere AFAIK.


Amos

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

Re: [squid-users] Transparent proxy and non-transparent proxy on the same squid.

[Antony Stone]

On Thursday 11 August 2016 at 22:15:12, Daniel Reif wrote:

> There is any way to run squid in transparent mode and non-transparent
> mode in the same squid?

Yes - you define one listener on port 80 for the intercept traffic (which 
*must* 
be redirected on the Squid box, so it must either be in the routing path from 
your clients to the Interet, or else it must get policy-routed traffic from 
some 
point in the default routing path), and another listener on port 3128 (or 
whatever else you prefer) for the non-transparent traffic.

If you haven't found a suitable guide to let you combine the two, I suggest 
you follow two guides, one for transparent procying, and one for direct 
proxying, combine the two sets of directives, and then come back to us with 
your squid.conf if you have any problems.

But yes, Squid can certainly do it.


Regards,


Antony.

-- 
If you were ploughing a field, which would you rather use - two strong oxen or 
1024 chickens?

 - Seymour Cray, pioneer of supercomputing

   Please reply to the list;
 please *don't* CC me.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Transparent proxy with Ubuntu 15.04 and Squid3

[Amos Jeffries]

On 2/10/2015 8:15 a.m., Jake wrote:
> I have a Squid/Dansguardian proxy server that successfully works when
> the client web browser is manually configured to use the proxy address:port.
> 
> What I want to do is configure a transparent proxy server, presuming I
> wouldn't have to manually configure browsers.

"transparent proxy" is not what you think.

The best choice is to use WPAD/PAC auto-configuration. That gets you all
the benefts of manual configuration without the troubles of either
manual or interception.


> 
> My LAN environment diagram:
> http://imgur.com/0MybmwE
> 
> This is a home network environment with a cable modem, wifi router,
> client web browsers, and I have added the proxy server as a virtualized
> VMware server.
> 
> For the proxy server I have two virtual network cards on the same subnet:
> eth0 192.168.1.14 (gateway and the proxy address)
> eth1 192.168.1.15
> 
> Is it possible the proxy server can intercept traffic from the clients,
> when the clients have direct access to the internet router? I don't
> understand how traffic is "intercepted" in this diagram.

The router needs to route the packets to/through the proxy server.

> 
> Do I need to change something on the router?

Yes.

> 
> How do I configure for proxy transparency?
> 

You didn't say waht yoru router software was...


> I've read some configurations, but they were confusing, or out of date,
> or specialized without much explanation.

The explanation for that is each router software being different. Config
for one routing application will not work for others.

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

Re: [squid-users] Transparent proxy before NAT

[Amos Jeffries]

On 14/07/2015 8:34 a.m., John Pearson wrote:
> Thanks Yuri for the response, I understand. I do have Shorewall configured
> and I understand the security implications. My Router is also the Wireless
> AP, so I want to try out this setup without having to buy another Wireless
> AP.
> 
> I don't mind it being complex, do you have any suggestions on getting
> Internet <---> Squid <---> Router (NAT) working ?
> 

You wont ever get that happening. The NAT intercept step between clients
and Squid must happen on the Squid device directly so Squid has access
to the kernel NAT mappings. This is not optional.


The best way if you are able to do it is to turn the Router into a plain
AP point. And the Squid device into router + NAT device.

Its easy enough to setup the Squid device with outgoing NAT rules same
as the router would have used. You can even do DHCP there as well if you
like.



The alternative is to go with the Squid device wired into the router so
traffic flow is:
 clients -> Router (no NAT!) -> Squid -> Router (NAT) -> Internet

"Router" can be one device if you have sufficient control over the
ebtables and iptables rules to split the pre-Squid and post-Squid packet
flows

But that has two big problems when only one router device is used:

 1) Most consumer grade wifi+modem+router devices and even some
commercial grade ones dont support the level of iptables config needed.

 2) With one router device the router<->Squid NIC cards bandwidth
capacity is halved, since all traffic travels over it twice. Likewise
the router CPU cyces for networking are halved.


In both configs setup the clients with the Squid device static IP as
their gateway as Yuri said. The router just happens to be the path they
use to reach the Squid gateway device.

The first config Squid uses Internet uplink directly as its gateway, and
performs NAT MASQUERADE for outgoing traffic.

The second config the Squid device uses the Router as its gateway (same
as the clients would normally have done). Packets go to the Internet via
there.


Amos



> Thanks!
> 
> On Mon, Jul 13, 2015 at 1:33 PM, John Pearson 
> wrote:
> 
>> Thanks Yuri for the response, I understand. I do have Shorewall configured
>> and I understand the security implications. My Router is also the Wireless
>> AP, so I want to try out this setup without having to buy another Wireless
>> AP.
>>
>> I don't mind it being complex, do you have any suggestions on getting
>> Internet <---> Squid <---> Router (NAT) working ?
>>
>> Thanks!
>>
>> On Mon, Jul 13, 2015 at 1:26 PM, Yuri Voinov  wrote:
>>
>>>
> Ah,
> 
> forgot about:
> 
> Your squid in scheme I wrote will have static gray IP. And this IP must
> be excluded from DHCP pool on router.
> 
> 14.07.15 2:15, John Pearson пишет:
> Hi Everyone,
>
> My setup is: Internet <--> Squid-eth0 <--> Squid-eth1 <--> Router <-->
> Devices
>
> Currently the Router is doing NAT and DHCP for the devices connected to
> it.
> Squid is in transparent mode. I set up a bridge ( br0). I set up the
> ebtables and iptables. It works but I want to figure out a way without
> having to configure Squid server or Router with hardcoded addresses.
>
> I have it working with either setup:
> 1. Remove the bridge ( br0) and setup the Squid server eth1 as a static
> IP
> address and set Squid server IP address as gateway in Router settings.
> 2. Since Squid server is in bridge mode, I can hard code IP address in a
> Squid ACL as all traffic appears to come this IP address from the
> router.
>
> I want a way to do this without any setup, basically to take a Squid box
> and place it before a Router. Is there a way to do this ?
>
> A few ideas that might be wrong:
> 1. In bridge mode, http_access allow CURRENTIPADDRESS  (
> CURRENTIPADDRESS
> is the dynamic IP address provided the ISP ) Is there a way to obtain
> this
> in the squid.conf file ?
> 2. Setup a DHCP server alongside Squid server and have Squid(DHCP) <-->
> Router(DHCP, NAT) and have same dhcp address given to the Router in
> squid.conf as http_access allow localnet
>
> Thanks in advance!
>
>
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://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
>>>
>>>
>>
> 
> 
> 
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://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] Transparent proxy before NAT

[Yuri Voinov]

I use a bit another configuration:

http://wiki.squid-cache.org/ConfigExamples/Intercept/CiscoIOSv15Wccp2

As you can see, squid box placed between two routers. Front router uses 
NAT to white IP, back router has no NAT and configured with WCCPv2 
redirection. DMZ configured between two routers.


As I think, configuration you described will really strange and 
insecure. Yes, you can assign white IP to squid. No, you can't use squid 
as router or DHCP. Squid box can only work as intercepter for HTTP/HTTPS 
traffic and TCP/IP forwarder for another traffic.


As I said, more correct configuration will be:

Internet <-> Router <-> Transparent Squid box as gateway 
<---> devices.


This configuration works, I use it on my testing environment.

14.07.15 2:34, John Pearson пишет:
Thanks Yuri for the response, I understand. I do have Shorewall 
configured and I understand the security implications. My Router is 
also the Wireless AP, so I want to try out this setup without having 
to buy another Wireless AP.


I don't mind it being complex, do you have any suggestions on getting 
Internet <---> Squid <---> Router (NAT) working ?


Thanks!

On Mon, Jul 13, 2015 at 1:33 PM, John Pearson 
mailto:johnpearson...@gmail.com>> wrote:


Thanks Yuri for the response, I understand. I do have Shorewall
configured and I understand the security implications. My Router
is also the Wireless AP, so I want to try out this setup without
having to buy another Wireless AP.

I don't mind it being complex, do you have any suggestions on
getting Internet <---> Squid <---> Router (NAT) working ?

Thanks!

On Mon, Jul 13, 2015 at 1:26 PM, Yuri Voinov mailto:yvoi...@gmail.com>> wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ah,

forgot about:

Your squid in scheme I wrote will have static gray IP. And
this IP must be excluded from DHCP pool on router.

14.07.15 2:15, John Pearson пишет:
> Hi Everyone, > > My setup is: Internet <--> Squid-eth0 <--> Squid-eth1
<--> Router <--> > Devices > > Currently the Router is doing
NAT and DHCP for the devices connected to it. > Squid is in
transparent mode. I set up a bridge ( br0). I set up the >
ebtables and iptables. It works but I want to figure out a way
without > having to configure Squid server or Router with
hardcoded addresses. > > I have it working with either setup:
> 1. Remove the bridge ( br0) and setup the Squid server eth1
as a static IP > address and set Squid server IP address as
gateway in Router settings. > 2. Since Squid server is in
bridge mode, I can hard code IP address in a > Squid ACL as
all traffic appears to come this IP address from the router. >
> I want a way to do this without any setup, basically to take
a Squid box > and place it before a Router. Is there a way to
do this ? > > A few ideas that might be wrong: > 1. In bridge
mode, http_access allow CURRENTIPADDRESS  ( CURRENTIPADDRESS >
is the dynamic IP address provided the ISP ) Is there a way to
obtain this > in the squid.conf file ? > 2. Setup a DHCP
server alongside Squid server and have Squid(DHCP) <--> >
Router(DHCP, NAT) and have same dhcp address given to the
Router in > squid.conf as http_access allow localnet > >
Thanks in advance! > > >
> ___ >
squid-users mailing list > squid-users@lists.squid-cache.org
 >
http://lists.squid-cache.org/listinfo/squid-users

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEbBAEBCAAGBQJVpB7aAAoJENNXIZxhPexGJcgH+IcaMqoEwlcRYFNCWqKT/Msc
I6aMD/82Uw5ow/HayX/GrxCHTzYjdCzXDXJTP9cAnHZaMnvOPxtCGuVocEHNEiOa
sDsZC9P074hoANDEAYXycWF73auCxYg4jcg8dRtbZwVEazwYsMVN6ye5a3i9EaZM
/DotQ78htLNRJrLhoCO9yQBtJObcUs+eyOie4oxk4YWSfQMcjZOXen7U8K8KGQuH
cOBcodLJv/eP1T+CcEe3ATr8Szo+zQ648jG27pdy7XuPecek7sWllRnyq93fpkID
FnvOr21R3gLBBdStYty43PKQ/4Z3d4vp56aYEweKBsGJV9kVC2QMjDXLOzrbug==
=1pgP
-END PGP SIGNATURE-


___
squid-users mailing list
squid-users@lists.squid-cache.org

http://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


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

Re: [squid-users] Transparent proxy before NAT

[John Pearson]

Thanks Yuri for the response, I understand. I do have Shorewall configured
and I understand the security implications. My Router is also the Wireless
AP, so I want to try out this setup without having to buy another Wireless
AP.

I don't mind it being complex, do you have any suggestions on getting
Internet <---> Squid <---> Router (NAT) working ?

Thanks!

On Mon, Jul 13, 2015 at 1:33 PM, John Pearson 
wrote:

> Thanks Yuri for the response, I understand. I do have Shorewall configured
> and I understand the security implications. My Router is also the Wireless
> AP, so I want to try out this setup without having to buy another Wireless
> AP.
>
> I don't mind it being complex, do you have any suggestions on getting
> Internet <---> Squid <---> Router (NAT) working ?
>
> Thanks!
>
> On Mon, Jul 13, 2015 at 1:26 PM, Yuri Voinov  wrote:
>
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Ah,
>>
>> forgot about:
>>
>> Your squid in scheme I wrote will have static gray IP. And this IP must
>> be excluded from DHCP pool on router.
>>
>> 14.07.15 2:15, John Pearson пишет:
>> > Hi Everyone,
>> >
>> > My setup is: Internet <--> Squid-eth0 <--> Squid-eth1 <--> Router <-->
>> > Devices
>> >
>> > Currently the Router is doing NAT and DHCP for the devices connected to
>> it.
>> > Squid is in transparent mode. I set up a bridge ( br0). I set up the
>> > ebtables and iptables. It works but I want to figure out a way without
>> > having to configure Squid server or Router with hardcoded addresses.
>> >
>> > I have it working with either setup:
>> > 1. Remove the bridge ( br0) and setup the Squid server eth1 as a static
>> IP
>> > address and set Squid server IP address as gateway in Router settings.
>> > 2. Since Squid server is in bridge mode, I can hard code IP address in a
>> > Squid ACL as all traffic appears to come this IP address from the
>> router.
>> >
>> > I want a way to do this without any setup, basically to take a Squid box
>> > and place it before a Router. Is there a way to do this ?
>> >
>> > A few ideas that might be wrong:
>> > 1. In bridge mode, http_access allow CURRENTIPADDRESS  (
>> CURRENTIPADDRESS
>> > is the dynamic IP address provided the ISP ) Is there a way to obtain
>> this
>> > in the squid.conf file ?
>> > 2. Setup a DHCP server alongside Squid server and have Squid(DHCP) <-->
>> > Router(DHCP, NAT) and have same dhcp address given to the Router in
>> > squid.conf as http_access allow localnet
>> >
>> > Thanks in advance!
>> >
>> >
>> >
>> > ___
>> > squid-users mailing list
>> > squid-users@lists.squid-cache.org
>> > http://lists.squid-cache.org/listinfo/squid-users
>>
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v2
>>
>> iQEbBAEBCAAGBQJVpB7aAAoJENNXIZxhPexGJcgH+IcaMqoEwlcRYFNCWqKT/Msc
>> I6aMD/82Uw5ow/HayX/GrxCHTzYjdCzXDXJTP9cAnHZaMnvOPxtCGuVocEHNEiOa
>> sDsZC9P074hoANDEAYXycWF73auCxYg4jcg8dRtbZwVEazwYsMVN6ye5a3i9EaZM
>> /DotQ78htLNRJrLhoCO9yQBtJObcUs+eyOie4oxk4YWSfQMcjZOXen7U8K8KGQuH
>> cOBcodLJv/eP1T+CcEe3ATr8Szo+zQ648jG27pdy7XuPecek7sWllRnyq93fpkID
>> FnvOr21R3gLBBdStYty43PKQ/4Z3d4vp56aYEweKBsGJV9kVC2QMjDXLOzrbug==
>> =1pgP
>> -END PGP SIGNATURE-
>>
>>
>> ___
>> squid-users mailing list
>> squid-users@lists.squid-cache.org
>> http://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] Transparent proxy before NAT

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
Ah,

forgot about:

Your squid in scheme I wrote will have static gray IP. And this IP must
be excluded from DHCP pool on router.

14.07.15 2:15, John Pearson пишет:
> Hi Everyone,
>
> My setup is: Internet <--> Squid-eth0 <--> Squid-eth1 <--> Router <-->
> Devices
>
> Currently the Router is doing NAT and DHCP for the devices connected
to it.
> Squid is in transparent mode. I set up a bridge ( br0). I set up the
> ebtables and iptables. It works but I want to figure out a way without
> having to configure Squid server or Router with hardcoded addresses.
>
> I have it working with either setup:
> 1. Remove the bridge ( br0) and setup the Squid server eth1 as a static IP
> address and set Squid server IP address as gateway in Router settings.
> 2. Since Squid server is in bridge mode, I can hard code IP address in a
> Squid ACL as all traffic appears to come this IP address from the router.
>
> I want a way to do this without any setup, basically to take a Squid box
> and place it before a Router. Is there a way to do this ?
>
> A few ideas that might be wrong:
> 1. In bridge mode, http_access allow CURRENTIPADDRESS  ( CURRENTIPADDRESS
> is the dynamic IP address provided the ISP ) Is there a way to obtain this
> in the squid.conf file ?
> 2. Setup a DHCP server alongside Squid server and have Squid(DHCP) <-->
> Router(DHCP, NAT) and have same dhcp address given to the Router in
> squid.conf as http_access allow localnet
>
> Thanks in advance!
>
>
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQEbBAEBCAAGBQJVpB7aAAoJENNXIZxhPexGJcgH+IcaMqoEwlcRYFNCWqKT/Msc
I6aMD/82Uw5ow/HayX/GrxCHTzYjdCzXDXJTP9cAnHZaMnvOPxtCGuVocEHNEiOa
sDsZC9P074hoANDEAYXycWF73auCxYg4jcg8dRtbZwVEazwYsMVN6ye5a3i9EaZM
/DotQ78htLNRJrLhoCO9yQBtJObcUs+eyOie4oxk4YWSfQMcjZOXen7U8K8KGQuH
cOBcodLJv/eP1T+CcEe3ATr8Szo+zQ648jG27pdy7XuPecek7sWllRnyq93fpkID
FnvOr21R3gLBBdStYty43PKQ/4Z3d4vp56aYEweKBsGJV9kVC2QMjDXLOzrbug==
=1pgP
-END PGP SIGNATURE-

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

Re: [squid-users] Transparent proxy before NAT

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
And beware: Your current configuration is insecure. Very insecure.
Especially if you haven't firewall configured on squid box.

14.07.15 2:15, John Pearson пишет:
> Hi Everyone,
>
> My setup is: Internet <--> Squid-eth0 <--> Squid-eth1 <--> Router <-->
> Devices
>
> Currently the Router is doing NAT and DHCP for the devices connected
to it.
> Squid is in transparent mode. I set up a bridge ( br0). I set up the
> ebtables and iptables. It works but I want to figure out a way without
> having to configure Squid server or Router with hardcoded addresses.
>
> I have it working with either setup:
> 1. Remove the bridge ( br0) and setup the Squid server eth1 as a static IP
> address and set Squid server IP address as gateway in Router settings.
> 2. Since Squid server is in bridge mode, I can hard code IP address in a
> Squid ACL as all traffic appears to come this IP address from the router.
>
> I want a way to do this without any setup, basically to take a Squid box
> and place it before a Router. Is there a way to do this ?
>
> A few ideas that might be wrong:
> 1. In bridge mode, http_access allow CURRENTIPADDRESS  ( CURRENTIPADDRESS
> is the dynamic IP address provided the ISP ) Is there a way to obtain this
> in the squid.conf file ?
> 2. Setup a DHCP server alongside Squid server and have Squid(DHCP) <-->
> Router(DHCP, NAT) and have same dhcp address given to the Router in
> squid.conf as http_access allow localnet
>
> Thanks in advance!
>
>
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQEcBAEBCAAGBQJVpB57AAoJENNXIZxhPexG/JEIAI06Ksm0R7n2O8h5mHO0HgFe
8r/bmmcKcmkmRiWXJGAq/zKY5oBuzeNocuwS4HNkj+//hYkdRpTyF8+ozFNeoSYj
2AnEkmcjZLjGk3kG/RcBpdIY8n1iXBQuD0I/4UrTleeG282tVeZJbe+qWVXvG1nB
7N7dyB/kYeKnlmhUNfCCbhyoLD3dJyC+8ECYjwAKIWspdPnzAPUFMIPc1NmWnMWU
IiQJe73wCITVd100YCSeCBbOvlvoYbWbQrymOb7rWMVJJq/qQxa2R27660DHAvjj
pnF0bnh94kvjFJ7Pk3AXM3d4jXKt0DbJLiXuw6Ch2MzZcfN0cYfpTDiGvH6XcBY=
=dAJc
-END PGP SIGNATURE-

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

Re: [squid-users] Transparent proxy before NAT

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
Note:

If you want to use two NIC onto Squid box, you need to configure this
box TCP stack as a static router.

But more better to aggregate both NIC and connect router and squid box
with switch.

14.07.15 2:15, John Pearson пишет:
> Hi Everyone,
>
> My setup is: Internet <--> Squid-eth0 <--> Squid-eth1 <--> Router <-->
> Devices
>
> Currently the Router is doing NAT and DHCP for the devices connected
to it.
> Squid is in transparent mode. I set up a bridge ( br0). I set up the
> ebtables and iptables. It works but I want to figure out a way without
> having to configure Squid server or Router with hardcoded addresses.
>
> I have it working with either setup:
> 1. Remove the bridge ( br0) and setup the Squid server eth1 as a static IP
> address and set Squid server IP address as gateway in Router settings.
> 2. Since Squid server is in bridge mode, I can hard code IP address in a
> Squid ACL as all traffic appears to come this IP address from the router.
>
> I want a way to do this without any setup, basically to take a Squid box
> and place it before a Router. Is there a way to do this ?
>
> A few ideas that might be wrong:
> 1. In bridge mode, http_access allow CURRENTIPADDRESS  ( CURRENTIPADDRESS
> is the dynamic IP address provided the ISP ) Is there a way to obtain this
> in the squid.conf file ?
> 2. Setup a DHCP server alongside Squid server and have Squid(DHCP) <-->
> Router(DHCP, NAT) and have same dhcp address given to the Router in
> squid.conf as http_access allow localnet
>
> Thanks in advance!
>
>
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQEcBAEBCAAGBQJVpB5MAAoJENNXIZxhPexGedUH/j3tw39S2TmmU+NR/Y/ERvWK
xLwn+ixsahMtsV26M7Petp58D4mJp8ZZclFl1xf5MxOfyRv5c/n6U090asy08TRu
KBrC0rHwJr76tdRsNqLeKmGOKejGKh7H8Y24j8TZ+8dYA2Csv4DK5O8VXQAaTB9w
NIdsszXUvv2I9HtF+CPWbmIjljG0IzpqKKDMoEZtkhJXOoSzGYCO9HXNqF7H22Kz
6C7EOtOOUpu635I6IL1QLbkuoBNHgTuO4bVC8pa3unCGSdCDwOPPRbivcNEOI90x
dl5ehT7W2hQ1pZze7p5Wiy2h4AnyXc5c7bzZNOTE5JF95Kw+45Q/fRRbvXUhv/c=
=zEMT
-END PGP SIGNATURE-

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

Re: [squid-users] Transparent proxy before NAT

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
Too complex setup for simple task.

You can simple re-connect squid box before router and configure it as
gateway for devices. And setup NAT redirection directly onto squid box.

Something like this:

Internet <-> Router + DHCP + NAT <--> Squid box + NAT
redirection <--> Devices

Router will use NAT from white IP to internal IP's. Squid box will use
port redirection and will configure like forwarding IP box.

That's it.

14.07.15 2:15, John Pearson пишет:
> Hi Everyone,
>
> My setup is: Internet <--> Squid-eth0 <--> Squid-eth1 <--> Router <-->
> Devices
>
> Currently the Router is doing NAT and DHCP for the devices connected
to it.
> Squid is in transparent mode. I set up a bridge ( br0). I set up the
> ebtables and iptables. It works but I want to figure out a way without
> having to configure Squid server or Router with hardcoded addresses.
>
> I have it working with either setup:
> 1. Remove the bridge ( br0) and setup the Squid server eth1 as a static IP
> address and set Squid server IP address as gateway in Router settings.
> 2. Since Squid server is in bridge mode, I can hard code IP address in a
> Squid ACL as all traffic appears to come this IP address from the router.
>
> I want a way to do this without any setup, basically to take a Squid box
> and place it before a Router. Is there a way to do this ?
>
> A few ideas that might be wrong:
> 1. In bridge mode, http_access allow CURRENTIPADDRESS  ( CURRENTIPADDRESS
> is the dynamic IP address provided the ISP ) Is there a way to obtain this
> in the squid.conf file ?
> 2. Setup a DHCP server alongside Squid server and have Squid(DHCP) <-->
> Router(DHCP, NAT) and have same dhcp address given to the Router in
> squid.conf as http_access allow localnet
>
> Thanks in advance!
>
>
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQEcBAEBCAAGBQJVpB3IAAoJENNXIZxhPexGjJYH/R0ESKEeEzla/v/sceiPBmds
r9//Nif+sGgeD8rRzVdNOYwv2tR5OpSjRr4j8F2QQYg4wO+myEUL2V6a8ATsOcOa
WM6xNiK34fbzT48mOTwRB2tsbURdxWxl1HB+7RnjSw596i5Jb/c24AlSburUKFMI
iTBppm/9ROT8lDAUAWUUx1W0SLUvylvZp4wNdA5QAY0F7uLO1X8uFXMbJXRarTYy
9lahI4dOO4SakHtsHpIoIT0uu1GGWzWHhN4c1lsER5/wX+oukpe9hRMgPYqeKJox
M/wIn7EdX2DpnBt9bLZGgkcTtKDAE0j8yfFvB3/at81zvQq8MsJSh24Hq6e4I/I=
=UG9i
-END PGP SIGNATURE-

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

Re: [squid-users] transparent proxy splice using dstdomain issue

[Amos Jeffries]

On 8/07/2015 1:54 a.m., S.Kirschner wrote:
> Amos Jeffries wrote
>> On 7/07/2015 11:45 p.m., S.Kirschner wrote:
>>> I think the issues exist because the reverse lookup dont got the anwser
>>> "sparkasse.de", but why it does not use the hostname from the dns request
>>> to
>>> the dns-server ?
>>
>> Because Squid is not a DNS server.
>>
>> The HTTP message details including URL where dstdomain comes from are
>> encrypted at the time you are trying to use the dstdomain ACL.
> 
> Yes but, in pfsense a dns server is installed, so on these host a dns server
> is running. Also i tried to use the google DNS 

Location of the DNS resolver has nothing to do with how Squid (or DNS)
operates.


> 
> Here now the entries from the cache.log
> 
> With sparkasse.de in /etc/hosts
> #2015/06/19 14:03:03.907 kid1| DomainData.cc(108) match: aclMatchDomainList:
> checking '212.34.69.3'
> #2015/06/19 14:03:03.907 kid1| DomainData.cc(113) match: aclMatchDomainList:
> '212.34.69.3' NOT found
> #2015/06/19 14:03:03.908 kid1| DomainData.cc(108) match: aclMatchDomainList:
> checking 'sparkasse.de'
> #2015/06/19 14:03:03.908 kid1| DomainData.cc(113) match: aclMatchDomainList:
> 'sparkasse.de' found

These are the rDNS host name in your hosts file for that IP.

In DNS hosts file entries are authoritative and override any gobal
registrations.


> #2015/06/19 14:03:03.908 kid1| Acl.cc(158) matches: checked: bypass = 1
> #2015/06/19 14:03:03.908 kid1| Acl.cc(158) matches: checked: (ssl_bump rule)
> = 1
> #2015/06/19 14:03:03.908 kid1| Acl.cc(158) matches: checked: (ssl_bump
> rules) = 1
> 
> Without sparkasse.de in /etc/hosts
> #2015/06/19 14:05:19.842 kid1| DomainData.cc(108) match: aclMatchDomainList:
> checking '212.34.69.3'
> #2015/06/19 14:05:19.842 kid1| DomainData.cc(113) match: aclMatchDomainList:
> '212.34.69.3' NOT found
> #2015/06/19 14:05:19.842 kid1| DomainData.cc(108) match: aclMatchDomainList:
> checking 'rev-212.34.69.3.rev.izb.net'
> #2015/06/19 14:05:19.842 kid1| DomainData.cc(113) match: aclMatchDomainList:
> 'rev-212.34.69.3.rev.izb.net' NOT found

The real host name registered in global rDNS for that IP.

If I assume you configured Squid to use the pfsense DNS resolver. That
is the hostname it presents Squid with for that IP.

Note that domain name and host name are different concepts...
* one domain name DNS entry possibly points at multiple IPs, and
* multiple domain names can possibly point at one IP, but
* each IP rDNS points at exactly one host name.

So,
 212.34.69.3 is one of possibly many IPs for sparkasse.de.
 sparkasse.de is one of may names pointing at 212.34.69.3.


But, rev-212.34.69.3.rev.izb.net is the host name for 212.34.69.3.
 (which also means rev-212.34.69.3.rev.izb.net is the primary one of may
names pointing at 212.34.69.3).


Problem: since that IP has many domain names pointing at it. Which one
did the user lookup in *forward* DNS to get to that IP address?

 They could have as easily gone to https://rev-212.34.69.3.rev.izb.net/
as to https://sparkasse.de/ and the TCP connection would look identical
to Squid.


When dealing with HTTP (not encrypted) the answer is to look at the HTTP
message headers and see what they are requesting. dstdomain does that.

 BUT ... in HTTPS those headers are encrypted. And you are currently
deciding whether or not its appropriate to try and decrypt at all.

 Meaning the HTTP URL domain used by dstdomain is unavailable, and thus
dstdomain will not work properly.


> #2015/06/19 14:05:19.842 kid1| Acl.cc(158) matches: checked: bypass = 0
> #2015/06/19 14:05:19.842 kid1| Acl.cc(158) matches: checked: (ssl_bump rule)
> = 0
> 

The proper solution for HTTPS is to use the correct ACL type
("ssl::server_name") designed for use in your situation. That uses the
non-encrypted TLS metadata, which provides the server hostname.


Despite popular myths TLS is not end-to-end (user-to-origin). It is
point-to-point (client-to-server) encryption, with maybe multiple hops
along the way.

The TLS server name metadata will only give you the hostname of the
server the client was contacting. With SNI it is usually (but no
guarantee) the domain name. When SNI is not available it's down to TLS
certificate SubjectName that could as easily be a TLS proxy or CDN
service in front of the real server(s) and in fact its usually states a
whole list of alternative names, and regex patterns!! of domain names,
which the cert might be used for.

The definitions for Site, Domain name, host name (note the space),
hostname, and X.509 SubjectName are different for good reasons. So are
the ACL definitions.

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

Re: [squid-users] transparent proxy splice using dstdomain issue

[S.Kirschner]

Amos Jeffries wrote
> On 7/07/2015 11:45 p.m., S.Kirschner wrote:
>> I think the issues exist because the reverse lookup dont got the anwser
>> "sparkasse.de", but why it does not use the hostname from the dns request
>> to
>> the dns-server ?
> 
> Because Squid is not a DNS server.
> 
> The HTTP message details including URL where dstdomain comes from are
> encrypted at the time you are trying to use the dstdomain ACL.

Yes but, in pfsense a dns server is installed, so on these host a dns server
is running. Also i tried to use the google DNS 

Here now the entries from the cache.log

With sparkasse.de in /etc/hosts
#2015/06/19 14:03:03.907 kid1| DomainData.cc(108) match: aclMatchDomainList:
checking '212.34.69.3'
#2015/06/19 14:03:03.907 kid1| DomainData.cc(113) match: aclMatchDomainList:
'212.34.69.3' NOT found
#2015/06/19 14:03:03.908 kid1| DomainData.cc(108) match: aclMatchDomainList:
checking 'sparkasse.de'
#2015/06/19 14:03:03.908 kid1| DomainData.cc(113) match: aclMatchDomainList:
'sparkasse.de' found
#2015/06/19 14:03:03.908 kid1| Acl.cc(158) matches: checked: bypass = 1
#2015/06/19 14:03:03.908 kid1| Acl.cc(158) matches: checked: (ssl_bump rule)
= 1
#2015/06/19 14:03:03.908 kid1| Acl.cc(158) matches: checked: (ssl_bump
rules) = 1

Without sparkasse.de in /etc/hosts
#2015/06/19 14:05:19.842 kid1| DomainData.cc(108) match: aclMatchDomainList:
checking '212.34.69.3'
#2015/06/19 14:05:19.842 kid1| DomainData.cc(113) match: aclMatchDomainList:
'212.34.69.3' NOT found
#2015/06/19 14:05:19.842 kid1| DomainData.cc(108) match: aclMatchDomainList:
checking 'rev-212.34.69.3.rev.izb.net'
#2015/06/19 14:05:19.842 kid1| DomainData.cc(113) match: aclMatchDomainList:
'rev-212.34.69.3.rev.izb.net' NOT found
#2015/06/19 14:05:19.842 kid1| Acl.cc(158) matches: checked: bypass = 0
#2015/06/19 14:05:19.842 kid1| Acl.cc(158) matches: checked: (ssl_bump rule)
= 0

The ssl accept error in cache.log
#2015/06/19 14:05:19.825 kid1| Checklist.cc(61) markFinished: 0x8041b7798
answer ALLOWED for match
#2015/06/19 14:05:19.825 kid1| Checklist.cc(161) checkCallback:
ACLChecklist::checkCallback: 0x8041b7798 answer=ALLOWED
#2015/06/19 14:05:19.825 kid1| client_side_request.cc(1527) sslBumpNeed:
sslBump required: peek
#2015/06/19 14:05:19.825 kid1| client_side_request.cc(115)
~ClientRequestContext: 0x807468098 ClientRequestContext destructed
#2015/06/19 14:05:19.825 kid1| client_side_request.cc(1829) doCallouts:
calling processRequest()
#2015/06/19 14:05:19.825 kid1| store.cc(780) storeCreatePureEntry:
storeCreateEntry: '212.34.69.3:443'
#2015/06/19 14:05:19.825 kid1| MemObject.cc(97) MemObject: new MemObject
0x807567f40
#2015/06/19 14:05:19.825 kid1| store.cc(485) lock: storeCreateEntry locked
key [null_store_key] e:=V/0x80755ada0*1
#2015/06/19 14:05:19.825 kid1| store_key_md5.cc(89) storeKeyPrivate:
storeKeyPrivate: CONNECT 212.34.69.3:443
#2015/06/19 14:05:19.825 kid1| store.cc(449) hashInsert:
StoreEntry::hashInsert: Inserting Entry e:=IV/0x80755ada0*1 key
'04808DEC55BF24579C431922F1A83DE0'
#2015/06/19 14:05:19.840 kid1| client_side.cc(4245) clientPeekAndSpliceSSL:
SSL_accept failed.
#2015/06/19 14:05:19.840 kid1| client_side.cc(4245) clientPeekAndSpliceSSL:
SSL_accept failed.





--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/transparent-proxy-splice-using-dstdomain-issue-tp4672088p4672095.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] transparent proxy splice using dstdomain issue

[Amos Jeffries]

On 7/07/2015 11:45 p.m., S.Kirschner wrote:
> Hi I´m using squid version 3.5.3 as transparent proxy in pfsense and got an
> issue with my configuration.
> 
> I would like to bump ssl connections and some should be spliced(for the
> example I used "sparkasse.de"), in my case banking sites should be spliced.
> 
> Its working fine when i use IP´s for the acl´s or insert the hostname in the
> /etc/hosts,
> but I think both cant be the solution.
> 
> I think the issues exist because the reverse lookup dont got the anwser
> "sparkasse.de", but why it does not use the hostname from the dns request to
> the dns-server ?

Because Squid is not a DNS server.

The HTTP message details including URL where dstdomain comes from are
encrypted at the time you are trying to use the dstdomain ACL.

Please upgrade to the latest 3.5 release (today that is 3.5.6) and use
the "ssl::server_name" ACL instead of dstdomain for ssl_bump access
controls. It grabs the domain name (if any) from TLS directly without
needing decryption first.

> 
> Also got errors that the ssl accept failed.
> 
> Below you could see my squid.conf and the entries from the cache.log for
> both cases.
> 
> *Without hostname in etc/hosts*
> 
> 
> *With hostname in etc/hosts*
> 
> 
> *SSL accept log entries*
> 
> 
> *Squid.conf*
> 

Please be aware when using Nabble interface that fancy embeded
quotations are not sent to the mailing list. Only the plain message text.

Amos

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

Re: [squid-users] Transparent Proxy Configuration

[Amos Jeffries]

On 1/07/2015 6:21 a.m., Chris Greene wrote:
> I’ve had Squid running on Ubuntu for a few weeks.  I’d configured the
> proxy settings in the browsers.  Everything has been working well and
> I've been pleased with the results.  But now I need to make this a
> transparent proxy and I’m running into trouble & need some help.
> 
> I’ve got a Destination NAT rule set up on my router to forward TCP port
> 80 traffic to my proxy.

There is the problem. The NAT must be done on the Squid box, not the router.

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

Re: [squid-users] Transparent Proxy Configuration

[James Lay]

On 2015-06-30 12:21 PM, Chris Greene wrote:

I’ve had Squid running on Ubuntu for a few weeks.  I’d configured the
proxy settings in the browsers.  Everything has been working well and
I've been pleased with the results.  But now I need to make this a
transparent proxy and I’m running into trouble & need some help.

I’ve got a Destination NAT rule set up on my router to forward TCP
port 80 traffic to my proxy.  And I removed proxy configuration
settings from the browsers.  After enabling this DNAT rule, I see
requests being logged to /var/log/squid3/access.log.

Results when navigating to http://www.google.com:
The following error was encountered while trying to retrieve the URL: /
  Invalid URL
Some aspect of the requested URL is incorrect.
Some possible problems are:
-Missing or incorrect access protocol (should be “http://” or similar)
-Missing hostname
-Illegal double-escape in the URL-Path
-Illegal character in hostname; underscores are not allowed.


Next, I added "intercept" to http_port like so:
  "http_port  192.166.2.55:3128  intercept"
Results: Access Denied.

My abbreviated /etc/squid3/squid.conf looks like this:
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localhost
http_access allow all

I'm new to Squid/Ubuntu, so I likely overlooked something.  What am I
missing?  What troubleshooting step(s) should I take next?
-DG


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


What's your DNAT line?  Assuming squid is on the box that you're running 
the DNAT line on...here's mine...redirect is all you need if the 
firewall/gateway is on the same box as squid:


$IPTABLES -t nat -A PREROUTING -i eth0 -s 192.168.1.96/28 -p tcp --dport 
80 -j REDIRECT --to-port 3128


And parts of my squid.conf:

acl localnet src 192.168.1.0/24

acl Safe_ports port 80
acl Safe_ports port 443

acl CONNECT method CONNECT
acl allowed_http_sites url_regex "/opt/etc/squid/http_url.txt"

http_access deny !Safe_ports
http_access deny CONNECT !SSL_Ports

http_access allow SSL_ports
http_access allow localnet
http_access deny all

http_port 3128 intercept


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

Re: [squid-users] transparent proxy

[Simon Dcunha]

Dear Amos,

Thanks for the immediate reply
i had checked the wiki but was just looking around if there was some stuff 
which is more easier to implement 

thanks and regards

simon

- Original Message -
From: "Amos Jeffries" 
To: squid-users@lists.squid-cache.org
Sent: Wednesday, May 13, 2015 12:48:45 PM
Subject: Re: [squid-users] transparent proxy

On 13/05/2015 8:45 p.m., Simon Dcunha wrote:
> Dear All,
> 
> I want to implement transparent proxy with wccp2. kindly appreciate if 
> someone can advise me a link explaining the steps to follow 
> 

That would be the Squid wiki.

<http://wiki.squid-cache.org/ConfigExamples#Interception>

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

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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

Re: [squid-users] transparent proxy

[Amos Jeffries]

On 13/05/2015 8:45 p.m., Simon Dcunha wrote:
> Dear All,
> 
> I want to implement transparent proxy with wccp2. kindly appreciate if 
> someone can advise me a link explaining the steps to follow 
> 

That would be the Squid wiki.



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

Re: [squid-users] transparent proxy original_dst err

[jaykbvt]

Hi Amos,

We've got response from Cisco team and they've agreed that destination IP
gets changed when request passes through Cisco ISG. 

They are taking reference for configuration from this doc

http://www.cisco.com/c/en/us/td/docs/ios/isg/configuration/guide/15_0s/isg_15_0s_book/isg_l4_redirect.html#wp1055689

Now they are very adamant that ISG l4 redirection works only this way. They
are asking us to configure squid in a manner to retrieve destination host
from http request.

I am not aware if its possible or not.

Any suggestions.?

Thanks & Regards,
Jaykbvt 



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/transparent-proxy-original-dst-err-tp4670846p4670967.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] transparent proxy original_dst err

[Amos Jeffries]

On 22/04/2015 7:31 a.m., jaykbvt wrote:
> Hi Amos,
> 
> Thanks for reply,
> 
> I think I got ur point. If I understood correctly,
> 
> if a user makes request for http://www.wikipedia.org then the client request
> header should look like:
> 
> src: client_IP:random_port
> dst: wikipedia.org(ip_address):http
> http request: http_request details. (host,url,etc..)
> 
> and squid should get the packet like that.

correct.

> 
> But since Cisco ISG is in between which seems to be changing the client
> request header like:
> 
> src: client_IP:random_port
> dst: squid_IP:http
> http request: http_request details. (host,url,etc..)
> 
> and eventually squid fails to understand where to send http_request.

correct.

> 
> And thats why we should look at cisco ISG config.

yes.

> 
> my iptables config looks like:
> 
> iptables -t nat -A PREROUTING -s 10.58.200.33 -p tcp --dport 80 -j ACCEPT
> iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination
> 10.58.200.33:3129
> iptables -t nat -A POSTROUTING -j MASQUERADE
> iptables -t mangle -A PREROUTING -p tcp --dport 3129 -j DROP
> 

And correct.

Thats all we can help with I'm afraid until at least the Cisco issue is
resolved.

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

Re: [squid-users] transparent proxy original_dst err

[jaykbvt]

Hi Amos,

Thanks for reply,

I think I got ur point. If I understood correctly,

if a user makes request for http://www.wikipedia.org then the client request
header should look like:

src: client_IP:random_port
dst: wikipedia.org(ip_address):http
http request: http_request details. (host,url,etc..)

and squid should get the packet like that.

But since Cisco ISG is in between which seems to be changing the client
request header like:

src: client_IP:random_port
dst: squid_IP:http
http request: http_request details. (host,url,etc..)

and eventually squid fails to understand where to send http_request.

And thats why we should look at cisco ISG config.

my iptables config looks like:

iptables -t nat -A PREROUTING -s 10.58.200.33 -p tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination
10.58.200.33:3129
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -t mangle -A PREROUTING -p tcp --dport 3129 -j DROP

Pls comment.

Thanks & Regards,
Jaykbvt



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/transparent-proxy-original-dst-err-tp4670846p4670856.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] transparent proxy original_dst err

[Amos Jeffries]

On 22/04/2015 12:43 a.m., jaykbvt wrote:
> Hi Amos,
> 
> Thanks for reply.
> 
> 
> local=*10.58.200.33:80 remote=10.210.83.249:*3375 FD 10 flags=33: accepted 
> 
> 
> since squid is able to understand which client is requesting and following
> lines talks about request..
> 
> 
> parseHttpRequest: parseHttpRequest: req_hdr = {Host: www.wikipedia.org
> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:35.0) Gecko/20100101
> Firefox/35.0
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: en-US,en;q=0.5
> Accept-Encoding: gzip, deflate
> Connection: keep-alive
> 
> }
> 
> 
> you still feel there could be issue with Cisco erasing original dst-IP
> value.??

Yes. Its receiving the HTTP properly, but the broken TCP details
(10.58.200.33:80) prevent the requests being relayed on to the right server.

pPS. Unless you are working for Wikimedia and the 10.58.200.33:80
actually is the backend server address. In that case we would have gone
completely the wrong way to a fix.


> 
> The thing is Cisoco ISG is not managed by us. They are saying they've
> configured any incoming traffic from clients for web its redirected to
> squid's IP. I'm no expert on Cisco ISG, yet I've asked them to share the
> config pertaining to squid. I am awaiting their response.
> 
> Can you help me what should I ask them or point towards to check..and what
> type squid/iptables config combination should I do on my squid server given
> my network scenario.

As per the DNST page you used already:


Just make sure you have all 4 iptables rules listed on the page. Rather
than just the 1 you mentioned having.

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

Re: [squid-users] transparent proxy original_dst err

[jaykbvt]

Hi Amos,

Thanks for reply.


local=*10.58.200.33:80 remote=10.210.83.249:*3375 FD 10 flags=33: accepted 


since squid is able to understand which client is requesting and following
lines talks about request..


parseHttpRequest: parseHttpRequest: req_hdr = {Host: www.wikipedia.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:35.0) Gecko/20100101
Firefox/35.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

}


you still feel there could be issue with Cisco erasing original dst-IP
value.??

The thing is Cisoco ISG is not managed by us. They are saying they've
configured any incoming traffic from clients for web its redirected to
squid's IP. I'm no expert on Cisco ISG, yet I've asked them to share the
config pertaining to squid. I am awaiting their response.

Can you help me what should I ask them or point towards to check..and what
type squid/iptables config combination should I do on my squid server given
my network scenario.


Thanks & Regards,
Jaykbvt



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/transparent-proxy-original-dst-err-tp4670846p4670852.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] transparent proxy original_dst err

[Yuri Voinov]

21.04.15 17:20, Amos Jeffries пишет:

On 21/04/2015 10:44 p.m., jaykbvt wrote:

Hi,
My squid is configured in interception mode with

http_port 3130
http_port 3129 intercept

squid is running with single network card. request comes from the Cisco ISG
and internet is also allowed from the same Cisco ISG only.

I think the Cisco is doing NAT and erasing the original dst-IP value
from the client TCP packets. The problem needs to be fixed there (by not
NAT'ing on the Cisco).


Using NAT onto backoffice Cisco is not good idea. Usually, NAT only 
using on front router.





IPtables has been configured with following
squidip = 10.58.200.33
squid port = 3129

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to
10.58.200.33:3129



This above iptables NAT is changing something:80 to 10.58.200.33:3129.

When things are configured right the something is the origin web servers
IP the client was contacting. And the NAT un-mangling operation in Squid
converts the 10.58.200.33:3129 back to something:80.

NOTE: there are other iptables rules needed to prevent the from-Squid
traffic being looped back, and attackers contacting the Squid listening
port. But your proxy is not getting that far yet. So this is just a
heads-up for now.



Given bellow are entries in cache.log

+++
2015/04/21 15:50:20.576 kid1| client_side.cc(3412) httpAccept:
local=10.58.200.33:80 remote=10.210.83.249:3375 FD 10 flags=33: accepted

This is the connection info *after* the iptables NAT mangling is
un-done. The 10.58.200.33:3129 has succesfully been converted back into
something:80.

Unfortunately that something:80 dst-IP addresc received from the Cisco
was "10.58.200.33:80" as you can see in the local= parameter above.


Amos
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://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] transparent proxy original_dst err

[Amos Jeffries]

On 21/04/2015 10:44 p.m., jaykbvt wrote:
> Hi,
> My squid is configured in interception mode with 
> 
> http_port 3130
> http_port 3129 intercept
> 
> squid is running with single network card. request comes from the Cisco ISG
> and internet is also allowed from the same Cisco ISG only.

I think the Cisco is doing NAT and erasing the original dst-IP value
from the client TCP packets. The problem needs to be fixed there (by not
NAT'ing on the Cisco).

> 
> IPtables has been configured with following 
> squidip = 10.58.200.33
> squid port = 3129
> 
> iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to
> 10.58.200.33:3129
> 
> 

This above iptables NAT is changing something:80 to 10.58.200.33:3129.

When things are configured right the something is the origin web servers
IP the client was contacting. And the NAT un-mangling operation in Squid
converts the 10.58.200.33:3129 back to something:80.

NOTE: there are other iptables rules needed to prevent the from-Squid
traffic being looped back, and attackers contacting the Squid listening
port. But your proxy is not getting that far yet. So this is just a
heads-up for now.


> Given bellow are entries in cache.log
> 
> +++
> 2015/04/21 15:50:20.576 kid1| client_side.cc(3412) httpAccept:
> local=10.58.200.33:80 remote=10.210.83.249:3375 FD 10 flags=33: accepted

This is the connection info *after* the iptables NAT mangling is
un-done. The 10.58.200.33:3129 has succesfully been converted back into
something:80.

Unfortunately that something:80 dst-IP addresc received from the Cisco
was "10.58.200.33:80" as you can see in the local= parameter above.


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

Re: [squid-users] transparent proxy original_dst err

[Yuri Voinov]

So, what?

What's the problem?

21.04.15 16:44, jaykbvt пишет:

Hi,
My squid is configured in interception mode with

http_port 3130
http_port 3129 intercept

squid is running with single network card. request comes from the Cisco ISG
and internet is also allowed from the same Cisco ISG only.

IPtables has been configured with following
squidip = 10.58.200.33
squid port = 3129

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to
10.58.200.33:3129


Have also tried setting up config suggested at squid docs

DNAT - http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxDnat
Redirect -
http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxRedirect


But in all three setup I am getting

I'm getting following entries in my access.log file...

==
1429610951.208309 10.210.83.249 TCP_MISS/503 3808 GET
http://www.wikipedia.org/ - ORIGINAL_DST/10.58.200.33 text/html
1429611003.025  5 10.210.83.249 TCP_MISS/503 3808 GET
http://www.wikipedia.org/ - ORIGINAL_DST/10.58.200.33 text/html
1429611620.888306 10.210.83.249 TCP_MISS/503 3808 GET
http://www.wikipedia.org/ - ORIGINAL_DST/10.58.200.33 text/html
1429611625.952  4 10.210.83.249 TCP_MISS/503 3808 GET
http://www.wikipedia.org/ - ORIGINAL_DST/10.58.200.33 text/html
==

Given bellow are entries in cache.log

+++
2015/04/21 15:50:20.576 kid1| client_side.cc(3412) httpAccept:
local=10.58.200.33:80 remote=10.210.83.249:3375 FD 10 flags=33: accepted
2015/04/21 15:50:20.576 kid1| client_side.cc(258) readSomeData:
local=10.58.200.33:80 remote=10.210.83.249:3375 FD 10 flags=33: reading
request...
2015/04/21 15:50:20.581 kid1| client_side.cc(2322) parseHttpRequest:
parseHttpRequest: req_hdr = {Host: www.wikipedia.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:35.0) Gecko/20100101
Firefox/35.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

}
2015/04/21 15:50:20.581 kid1| client_side.cc(2326) parseHttpRequest:
parseHttpRequest: end = {
}
2015/04/21 15:50:20.581 kid1| client_side.cc(2330) parseHttpRequest:
parseHttpRequest: prefix_sz = 284, req_line_sz = 16
2015/04/21 15:50:20.582 kid1| client_side.cc(925) clientSetKeepaliveFlag:
clientSetKeepaliveFlag: http_ver = 1.1
2015/04/21 15:50:20.582 kid1| client_side.cc(927) clientSetKeepaliveFlag:
clientSetKeepaliveFlag: method = GET
2015/04/21 15:50:20.582 kid1| client_side_request.cc(1691) doCallouts: Doing
calloutContext->hostHeaderVerify()
2015/04/21 15:50:20.583 kid1| client_side.cc(258) readSomeData:
local=10.58.200.33:80 remote=10.210.83.249:3375 FD 10 flags=33: reading
request...
2015/04/21 15:50:20.884 kid1| client_side_request.cc(1698) doCallouts: Doing
calloutContext->clientAccessCheck()
2015/04/21 15:50:20.884 kid1| AccessCheck.cc(32) Start: adaptation off,
skipping
2015/04/21 15:50:20.884 kid1| client_side_request.cc(1727) doCallouts: Doing
calloutContext->clientAccessCheck2()
2015/04/21 15:50:20.884 kid1| client_side_request.cc(1746) doCallouts: Doing
clientInterpretRequestHeaders()
2015/04/21 15:50:20.885 kid1| client_side_request.cc(1835) doCallouts:
calling processRequest()
2015/04/21 15:50:20.888 kid1| client_side.cc(1626) keepaliveNextRequest:
ConnnStateData(local=10.58.200.33:80 remote=10.210.83.249:3375 FD 10
flags=33), Context(local=10.58.200.33:80 remote=10.210.83.249:3375 FD 10
flags=33)
2015/04/21 15:50:20.888 kid1| client_side_request.cc(265)
~ClientHttpRequest: httpRequestFree: http://www.wikipedia.org/
2015/04/21 15:50:20.888 kid1| client_side.cc(1696) keepaliveNextRequest:
local=10.58.200.33:80 remote=10.210.83.249:3375 FD 10 flags=33: calling
conn->readNextRequest()
2015/04/21 15:50:23.401 kid1| client_side.cc(2492) connFinishedWithConn:
local=10.58.200.33:80 remote=10.210.83.249:3375 FD 10 flags=33 closed
2015/04/21 15:50:23.401 kid1| client_side.cc(864) swanSong:
local=10.58.200.33:80 remote=10.210.83.249:3375 flags=33
2015/04/21 15:50:23.401 kid1| client_side.cc(4644) unpinConnection:
2015/04/21 15:50:23.402 kid1| client_side.cc(895) ~ConnStateData:
local=10.58.200.33:80 remote=10.210.83.249:3375 flags=33
2015/04/21 15:50:25.945 kid1| client_side.cc(3412) httpAccept:
local=10.58.200.33:80 remote=10.210.83.249:3378 FD 10 flags=33: accepted
2015/04/21 15:50:25.946 kid1| client_side.cc(258) readSomeData:
local=10.58.200.33:80 remote=10.210.83.249:3378 FD 10 flags=33: reading
request...
2015/04/21 15:50:25.947 kid1| client_side.cc(2322) parseHttpRequest:
parseHttpRequest: req_hdr = {Host: www.wikipedia.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:35.0) Gecko/20100101
Firefox/35.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

+++





any i

Re: [squid-users] Transparent Proxy

[a...@imaginers.org]

Hi,
first of all what error do you get at client side? Timeout? Blank Page?
I'm also running squid in an ISG setup, my squid version is Squid Cache: Version
3.1.10 on Centos 6.5
Few things to check:
1) please ensure the iptables-rules are hit correctly by issuing .f.e:
iptables -t mangle -vnL
 
2)if you see packets please make sure you do not have a redirect-loop, run squid
in debug mode or enable logging.
an example error can be found here:
http://www.squid-cache.org/mail-archive/squid-users/201004/0538.html
 
3) it's enough to configure port redirection once, you can do it with iptables
on the squid box (as you did below) or directly at the ISG, if you have defined
a server Pool it will look like that (probably ;))
redirect server-group REDIRECT_SERVERS
 server ip xx.xx.xx.xx port 80
for iptables-redirect
or
server ip xx.xx.xx.xx port 3129
for isg redirect
 
4) All problems I had with that setup basically were router configuration
errors. If L4 redirect does not work did you try next-hop rerouting without
altering the ports?
In a Cisco ISG setup make sure the squid box uses the ISG for the return traffic
and can't reach the clients directly, also make sure you are capturing the right
traffic and not blocking the return packets ect.
 
HTH,
Alex
 
 

> Jaydeep Kubavat  hat am 8. April 2015 um 13:50 geschrieben:
> 
>  Hi,
>   
>  As suggested by Amos...I've configured squid box with bellow mentioned
> config.
>   
>  I followed this doc
> http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxDnat
>   
>  1. Configured iptables as:
>   
>  Table: filter
>  Chain INPUT (policy ACCEPT)
>  num target prot opt source destination
>   
>  Chain FORWARD (policy ACCEPT)
>  num target prot opt source destination
>   
>  Chain OUTPUT (policy ACCEPT)
>  num target prot opt source destination
>   
>  Table: mangle
>  Chain PREROUTING (policy ACCEPT)
>  num target prot opt source destination
>  1 DROP tcp -- tcp dpt:3129
>   
>  Chain INPUT (policy ACCEPT)
>  num target prot opt source destination
>   
>  Chain FORWARD (policy ACCEPT)
>  num target prot opt source destination
>   
>  Chain OUTPUT (policy ACCEPT)
>  num target prot opt source destination
>   
>  Chain POSTROUTING (policy ACCEPT)
>  num target prot opt source destination
>   
>  Table: nat
>  Chain PREROUTING (policy ACCEPT)
>  num target prot opt source destination
>  1 ACCEPT tcp -- 10.58.200.33 tcp dpt:80
>  2 DNAT tcp -- tcp dpt:80
> to:
>   
>  Chain POSTROUTING (policy ACCEPT)
>  num target prot opt source destination
>  1 MASQUERADE all --
>   
>  Chain OUTPUT (policy ACCEPT)
>  num target prot opt source destination
>   
>   
>  2. squid with http_port 3129 intercept
>   
>  3. PCAP result
>   
>  "3","1.539609","10.210.83.247","10.58.200.33","TCP","68","28754→80 [SYN]
> Seq=0 Win=8192 Len=0 MSS=1360 WS=256 SACK_PERM=1"
>   
>  "4","1.539680","10.58.200.33","10.210.83.247","TCP","68","80→28754 [SYN, ACK]
> Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=64"
>   
>  "19","2.717863","10.58.200.33","10.210.83.247","TCP","68","[TCP
> Retransmission] 80→28754 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460
> SACK_PERM=1 WS=64"
>   
>  "31","7.613768","10.210.83.247","10.58.200.33","TCP","64","[TCP Spurious
> Retransmission] 28754→80 [SYN] Seq=0 Win=8192 Len=0 MSS=1360 SACK_PERM=1"
>   
>  "32","7.613835","10.58.200.33","10.210.83.247","TCP","68","[TCP
> Retransmission] 80→28754 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460
> SACK_PERM=1 WS=64"
>   
>  "43","8.917825","10.58.200.33","10.210.83.247","TCP","68","[TCP
> Retransmission] 80→28754 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460
> SACK_PERM=1 WS=64"
>   
>  "167","20.917840","10.58.200.33","10.210.83.247","TCP","68","[TCP
> Retransmission] 80→28754 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460
> SACK_PERM=1 WS=64"
>   
>  "485","44.917837","10.58.200.33","10.210.83.247","TCP","68","[TCP
> Retransmission] 80→28754 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460
> SACK_PERM=1 WS=64"
>   
>  "962","93.117870","10.58.200.33","10.210.83.247","TCP","68","[TCP
> Retransmission] 80→28754 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460
> SACK_PERM=1 WS=64"
>   
>  --
>  Thanks & Regards
>  Jaykbvt
> 
>  On Wed, Apr 8, 2015 at 2:50 PM, Jaydeep Kubavat   > wrote:
>> >Hi,
> > 
> >I've configured a transparent squid proxy on a centos 6.6 with single
> > NIC.
> > 
> >There is Cisco ISG in between with L4 redirection on www traffic.
> > 
> >The requests are coming on port 80 from client and ISG forwards that to
> > port 80 on my squid server.
> > 
> >So there is no iptables configured on squid server.
> > 
> >Client requests are not reaching upto my squid instance.
> > 
> >I'm getting the following in pcap on squid box.
> > 
> >=
> > 
>

Re: [squid-users] Transparent Proxy

[Jaydeep Kubavat]

Hi,

As suggested by Amos...I've configured squid box with bellow mentioned
config.

I followed this doc
http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxDnat

1. Configured iptables as:

Table: filter
Chain INPUT (policy ACCEPT)
num  target prot opt source   destination

Chain FORWARD (policy ACCEPT)
num  target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
num  target prot opt source   destination

Table: mangle
Chain PREROUTING (policy ACCEPT)
num  target prot opt source   destination
1DROP   tcp  --  0.0.0.0/00.0.0.0/0   tcp
dpt:3129

Chain INPUT (policy ACCEPT)
num  target prot opt source   destination

Chain FORWARD (policy ACCEPT)
num  target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
num  target prot opt source   destination

Chain POSTROUTING (policy ACCEPT)
num  target prot opt source   destination

Table: nat
Chain PREROUTING (policy ACCEPT)
num  target prot opt source   destination
1ACCEPT tcp  --  10.58.200.33 0.0.0.0/0   tcp
dpt:80
2DNAT   tcp  --  0.0.0.0/00.0.0.0/0   tcp
dpt:80 to:10.58.200.33:3129

Chain POSTROUTING (policy ACCEPT)
num  target prot opt source   destination
1MASQUERADE  all  --  0.0.0.0/00.0.0.0/0

Chain OUTPUT (policy ACCEPT)
num  target prot opt source   destination


2. squid with http_port 3129 intercept

3. PCAP result

"3","1.539609","10.210.83.247","10.58.200.33","TCP","68","28754→80 [SYN]
Seq=0 Win=8192 Len=0 MSS=1360 WS=256 SACK_PERM=1"

"4","1.539680","10.58.200.33","10.210.83.247","TCP","68","80→28754 [SYN,
ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=64"

"19","2.717863","10.58.200.33","10.210.83.247","TCP","68","[TCP
Retransmission] 80→28754 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460
SACK_PERM=1 WS=64"

"31","7.613768","10.210.83.247","10.58.200.33","TCP","64","[TCP Spurious
Retransmission] 28754→80 [SYN] Seq=0 Win=8192 Len=0 MSS=1360 SACK_PERM=1"

"32","7.613835","10.58.200.33","10.210.83.247","TCP","68","[TCP
Retransmission] 80→28754 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460
SACK_PERM=1 WS=64"

"43","8.917825","10.58.200.33","10.210.83.247","TCP","68","[TCP
Retransmission] 80→28754 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460
SACK_PERM=1 WS=64"

"167","20.917840","10.58.200.33","10.210.83.247","TCP","68","[TCP
Retransmission] 80→28754 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460
SACK_PERM=1 WS=64"

"485","44.917837","10.58.200.33","10.210.83.247","TCP","68","[TCP
Retransmission] 80→28754 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460
SACK_PERM=1 WS=64"

"962","93.117870","10.58.200.33","10.210.83.247","TCP","68","[TCP
Retransmission] 80→28754 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460
SACK_PERM=1 WS=64"

-- 
Thanks & Regards
Jaykbvt

On Wed, Apr 8, 2015 at 2:50 PM, Jaydeep Kubavat  wrote:

> Hi,
>
> I've configured a transparent squid proxy on a centos 6.6 with single NIC.
>
> There is Cisco ISG in between with L4 redirection on www traffic.
>
> The requests are coming on port 80 from client and ISG forwards that to
> port 80 on my squid server.
>
> So there is no iptables configured on squid server.
>
> Client requests are not reaching upto my squid instance.
>
> I'm getting the following in pcap on squid box.
>
> =
>
> "129","79.114808","10.210.83.246","10.58.200.33","TCP","76","39546→80
> [SYN] Seq=0 Win=14600 Len=0 MSS=1360 SACK_PERM=1 TSval=2686675 TSecr=0
> WS=64"
>
> "130","79.114946","10.58.200.33","10.210.83.246","TCP","76","80→39546
> [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=509402603
> TSecr=2686675 WS=64"
>
> "145","82.115674","10.210.83.246","10.58.200.33","TCP","76","[TCP Spurious
> Retransmission] 39546→80 [SYN] Seq=0 Win=14600 Len=0 MSS=1360 SACK_PERM=1
> TSval=2686976 TSecr=0 WS=64"
>
> "146","82.115748","10.58.200.33","10.210.83.246","TCP","76","[TCP
> Retransmission] 80→39546 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460
> SACK_PERM=1 TSval=509405604 TSecr=2686675 WS=64"
>
> "151","83.113859","10.58.200.33","10.210.83.246","TCP","76","[TCP
> Retransmission] 80→39546 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460
> SACK_PERM=1 TSval=509406603 TSecr=2686675 WS=64"
>
> "165","88.145376","10.210.83.246","10.58.200.33","TCP","76","[TCP Spurious
> Retransmission] 39546→80 [SYN] Seq=0 Win=14600 Len=0 MSS=1360 SACK_PERM=1
> TSval=2687578 TSecr=0 WS=64"
>
> "166","88.145450","10.58.200.33","10.210.83.246","TCP","76","[TCP
> Retransmission] 80→39546 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460
> SACK_PERM=1 TSval=509411634 TSecr=2686675 WS=64"
>
> "176","89.113837","10.58.200.33","10.210.83.246","TCP","76","[TCP
> Retransmission] 80→39546 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460
> SACK_PERM=1 TSval=509412603 TSecr=2686675 WS=64"
>
> "285","101.11383

Re: [squid-users] Transparent Proxy

[Amos Jeffries]

On 8/04/2015 9:20 p.m., Jaydeep Kubavat wrote:
> Hi,
> 
> I've configured a transparent squid proxy on a centos 6.6 with single NIC.
> 
> There is Cisco ISG in between with L4 redirection on www traffic.
> 
> The requests are coming on port 80 from client and ISG forwards that to
> port 80 on my squid server.

No, no it does not.

If you configured the remote router coorrectly:

It passes the packet to your Squid box for handling. The packet still
says port 80 *on some other server*.

Once the TCP SYN packet reaches the Squid box ...

> 
> So there is no iptables configured on squid server.
> 

... nothing happens to it. "Dropped on the floor.", etc.


If you configured the router badly:
 ... many varied things (all nasty) could happen.


Please have a read through:

in particular the sections:
* "Concepts of Interception Caching"
* "Requirements and methods for Interception Caching"
* "Getting your traffic to the right port on your Squid Cache"



> 
> my squid is configured default, only
> 
> http_port 3130

Port 3130 is generally used for ICP (which is a UDP based protocol)

> http_port 80 intercept

This has no use other than to potentially prevent your Squid being able
to open the listening port (unless the worker has root privileges - not
good).

Any port will do and a randomly selected port number higher than 1024 is
better. Only Squid and the machines TCP stack systems will have anything
to do with it - not the packets nor any external system.


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

Re: [squid-users] Transparent proxy with Peek and Splice feature.

[James Harper]

The following "works" for me:

# intercept for transparent proxy of ssl connections
https_port 3130 name=transproxyssl intercept ssl-bump 
generate-host-certificates=on dynamic_cert_mem_cache_size=4MB 
cert=/usr/local/squid/etc/ca.pem

# just testing with my laptop
acl james_src arp 11:11:11:11:11:11

# name of port used for transparent ssl interception
acl transproxyssl myportname transproxyssl

ssl_bump stare transproxyssl james_src
ssl_bump bump james_src
ssl_bump splice all

But "works" is probably a bit of an exaggeration. I was seeing lots of this 
sort of thing in the logs:
 
Error negotiating SSL on FD 75: error:1409F07F:SSL 
routines:SSL3_WRITE_PENDING:bad write retry (1/-1/0)
hold write on SSL connection on FD 65
BUG 3556: FD 112 is not an open socket.
assertion failed: Read.cc:69: "fd_table[conn->fd].halfClosedReader != NULL"

And squid restarting a lot. This was with squid-3.5.0.2-20141121-r13666 and so 
hopefully I was seeing some bugs that are now fixed, and it's not that I am 
abusing the configuration or something...

I'm upgrading to the latest snapshot now for further testing.

James


> -Original Message-
> From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On
> Behalf Of Vadim Rogoziansky
> Sent: Friday, 19 December 2014 11:29 PM
> To: squid-users@lists.squid-cache.org
> Subject: Re: [squid-users] Transparent proxy with Peek and Splice feature.
> 
> Any ideas, any thoughts?
> Thanks.
> 
> 
> 11/29/2014 6:17 AM, Amos Jeffries написав(ла):
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 28/11/2014 2:48 a.m., Vadim Rogoziansky wrote:
> >> Hello Amos.
> >>
> >> Thank you for answer.
> >>
> >> There was made an investigation related to squid's peek and splice
> >> issues in transparent mode. One-line explanation is as follows - in
> >> intercept mode squid can't get a server host name from the request
> >> header and uses clent IP address instead for both fake cert
> >> generation and as a SNI record in server bump SSL handshaking. This
> >> is the root of the problem. However this can be fixed if squid uses
> >> SNI field taken from client TLS Hello message for that purposes.
> >> Can you hack squid in this way? What do you think?
> > I think peek-n-splice is supposed to already be doing that.
> >
> > However it does depend on whether you are bumping the connection at
> > step 1 (before ClientHello), step 2 (after ClientHello, before
> > ServerHello), or step 3 (after both ClientHello and ServerHello) of
> > the TLS handshake whether the SNI details are present.
> >
> > Amos
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v2.0.22 (MingW32)
> >
> >
> iQEcBAEBAgAGBQJUeUjPAAoJELJo5wb/XPRj6QEIAOHrR8wmDcjkfgUh2UtPw
> pHP
> >
> vVkPMEuIrUq9Gxx3uSojCZjlFJPuCQ2UafS1p8LuxcEQ+TRmUFbAu4AkKoO2Ro
> Z5
> > 7fCGoiXTwn4TzFf0pLh9SPBq9j12OJ3uT28EEqbILrT0sbKP02xK/qiJfCLR61Ev
> >
> vprAdggapbKg/ns1l1H3BBgZR2A4W/abQPIq6/Eu/r+7nYK6L2oOdqPDWTJjud
> MV
> >
> 8D9sdOD9mYYryrdptU0GLh9Q/V5QEhipSkuA936iZ0Dfa2ZSr4gphJyaRAFWSMf
> 3
> >
> q502lZy+ASkDa2vAbjALRBgn3VwYWl8KBQcypUKF4UXtaLtF0EIrLMun+p4QxU
> M=
> > =44aG
> > -END PGP SIGNATURE-
> > ___
> > squid-users mailing list
> > squid-users@lists.squid-cache.org
> > http://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
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Transparent proxy with Peek and Splice feature.

[Vadim Rogoziansky]

Any ideas, any thoughts?
Thanks.


11/29/2014 6:17 AM, Amos Jeffries написав(ла):

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 28/11/2014 2:48 a.m., Vadim Rogoziansky wrote:

Hello Amos.

Thank you for answer.

There was made an investigation related to squid's peek and splice
issues in transparent mode. One-line explanation is as follows - in
intercept mode squid can't get a server host name from the request
header and uses clent IP address instead for both fake cert
generation and as a SNI record in server bump SSL handshaking. This
is the root of the problem. However this can be fixed if squid uses
SNI field taken from client TLS Hello message for that purposes.
Can you hack squid in this way? What do you think?

I think peek-n-splice is supposed to already be doing that.

However it does depend on whether you are bumping the connection at
step 1 (before ClientHello), step 2 (after ClientHello, before
ServerHello), or step 3 (after both ClientHello and ServerHello) of
the TLS handshake whether the SNI details are present.

Amos
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUeUjPAAoJELJo5wb/XPRj6QEIAOHrR8wmDcjkfgUh2UtPwpHP
vVkPMEuIrUq9Gxx3uSojCZjlFJPuCQ2UafS1p8LuxcEQ+TRmUFbAu4AkKoO2RoZ5
7fCGoiXTwn4TzFf0pLh9SPBq9j12OJ3uT28EEqbILrT0sbKP02xK/qiJfCLR61Ev
vprAdggapbKg/ns1l1H3BBgZR2A4W/abQPIq6/Eu/r+7nYK6L2oOdqPDWTJjudMV
8D9sdOD9mYYryrdptU0GLh9Q/V5QEhipSkuA936iZ0Dfa2ZSr4gphJyaRAFWSMf3
q502lZy+ASkDa2vAbjALRBgn3VwYWl8KBQcypUKF4UXtaLtF0EIrLMun+p4QxUM=
=44aG
-END PGP SIGNATURE-
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://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] Transparent proxy with Peek and Splice feature.

[Vadim Rogoziansky]

Yeap, squid perfectly "splice" the destination domain after step1 or 
step2 or step3 when the browser is set to use proxy directly.
But, it does not work in case of transparent proxy. Squid uses the 
destination IP address instead of SNI details.


The example of using client IP address is below:
2014/11/27 01:15:22.851| DomainData.cc(110) match: aclMatchDomainList: 
'212.42.77.232' NOT found


Thank you guys.


11/29/2014 6:17 AM, Amos Jeffries написав(ла):

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 28/11/2014 2:48 a.m., Vadim Rogoziansky wrote:

Hello Amos.

Thank you for answer.

There was made an investigation related to squid's peek and splice
issues in transparent mode. One-line explanation is as follows - in
intercept mode squid can't get a server host name from the request
header and uses clent IP address instead for both fake cert
generation and as a SNI record in server bump SSL handshaking. This
is the root of the problem. However this can be fixed if squid uses
SNI field taken from client TLS Hello message for that purposes.
Can you hack squid in this way? What do you think?

I think peek-n-splice is supposed to already be doing that.

However it does depend on whether you are bumping the connection at
step 1 (before ClientHello), step 2 (after ClientHello, before
ServerHello), or step 3 (after both ClientHello and ServerHello) of
the TLS handshake whether the SNI details are present.

Amos
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUeUjPAAoJELJo5wb/XPRj6QEIAOHrR8wmDcjkfgUh2UtPwpHP
vVkPMEuIrUq9Gxx3uSojCZjlFJPuCQ2UafS1p8LuxcEQ+TRmUFbAu4AkKoO2RoZ5
7fCGoiXTwn4TzFf0pLh9SPBq9j12OJ3uT28EEqbILrT0sbKP02xK/qiJfCLR61Ev
vprAdggapbKg/ns1l1H3BBgZR2A4W/abQPIq6/Eu/r+7nYK6L2oOdqPDWTJjudMV
8D9sdOD9mYYryrdptU0GLh9Q/V5QEhipSkuA936iZ0Dfa2ZSr4gphJyaRAFWSMf3
q502lZy+ASkDa2vAbjALRBgn3VwYWl8KBQcypUKF4UXtaLtF0EIrLMun+p4QxUM=
=44aG
-END PGP SIGNATURE-
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://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] Transparent proxy with Peek and Splice feature.

[Amos Jeffries]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 28/11/2014 2:48 a.m., Vadim Rogoziansky wrote:
> Hello Amos.
> 
> Thank you for answer.
> 
> There was made an investigation related to squid's peek and splice 
> issues in transparent mode. One-line explanation is as follows - in
> intercept mode squid can't get a server host name from the request
> header and uses clent IP address instead for both fake cert
> generation and as a SNI record in server bump SSL handshaking. This
> is the root of the problem. However this can be fixed if squid uses
> SNI field taken from client TLS Hello message for that purposes.
> Can you hack squid in this way? What do you think?

I think peek-n-splice is supposed to already be doing that.

However it does depend on whether you are bumping the connection at
step 1 (before ClientHello), step 2 (after ClientHello, before
ServerHello), or step 3 (after both ClientHello and ServerHello) of
the TLS handshake whether the SNI details are present.

Amos
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUeUjPAAoJELJo5wb/XPRj6QEIAOHrR8wmDcjkfgUh2UtPwpHP
vVkPMEuIrUq9Gxx3uSojCZjlFJPuCQ2UafS1p8LuxcEQ+TRmUFbAu4AkKoO2RoZ5
7fCGoiXTwn4TzFf0pLh9SPBq9j12OJ3uT28EEqbILrT0sbKP02xK/qiJfCLR61Ev
vprAdggapbKg/ns1l1H3BBgZR2A4W/abQPIq6/Eu/r+7nYK6L2oOdqPDWTJjudMV
8D9sdOD9mYYryrdptU0GLh9Q/V5QEhipSkuA936iZ0Dfa2ZSr4gphJyaRAFWSMf3
q502lZy+ASkDa2vAbjALRBgn3VwYWl8KBQcypUKF4UXtaLtF0EIrLMun+p4QxUM=
=44aG
-END PGP SIGNATURE-
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Transparent proxy with Peek and Splice feature.

[Vadim Rogoziansky]

Hello Amos.

Thank you for answer.

There was made an investigation related to squid's peek and splice 
issues in transparent mode.
One-line explanation is as follows - in intercept mode squid can't get a 
server host name from the request header and uses clent IP address 
instead for both fake cert generation and as a SNI record in server bump 
SSL handshaking. This is the root of the problem. However this can be 
fixed if squid uses SNI field taken from client TLS Hello message for 
that purposes. Can you hack squid in this way? What do you think?


Many thanks.


11/26/2014 11:33 AM, Amos Jeffries написав(ла):

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 26/11/2014 7:22 a.m., Vadim Rogoziansky wrote:

Hello All.

My goal is to do ssl bumping in transparent proxy mode with domain
exclude possibility. Let me tell you about squid's strange
behaviour when I'm trying to do it.

In browsers it says something like this: /This server could not
prove that it is www.ukr.net; its security certificate is
from212.42.76.253. This may be caused by a misconfiguration or an
attacker intercepting your connection.//
//NET::ERR_CERT_COMMON_NAME_INVALID// //Subject: 212.42.76.253// /
Looks like squid takes the CN from the certificate as IP address of
the destination domain.

Squid takes the IP address from the TCP packet. Which is all that is
available in NAT intercepted traffic at bumping step #1.

The ACLs you have therefore determine that "bump" action is to happen.
Correct?

The cert details are therefore mimic'ed from what gets delivered by
the server.

It may be that the server is depending on SNI to generate its own
cert, but since Squid deos not have that domain name already an
IP-based cert comes back.

It may also be that some ISP upstream of you is bumping the encryption
with client-first method.




But, everything works smoothly when I use proxy in non transparent
mode and put it to the browser directly .

In which case the browser sends domain name to the proxy in its
CONNECT message starting the HTTPS. The possible results are very
different.

Amos

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUdZ5sAAoJELJo5wb/XPRj0qIIANBjuFvq45hPmcaj/NYL6bza
7ttt5Gn+tn8E5KH7T4wfQhUXr91UIsYWfOswfnVAAlBevIO/iFVoDN5hAOveuhIl
ra/0eGti1EpZ3LHJiAqmo0mHsrz3v9+PAduVrXgUJLyYDiM0xctg0nRhj2u166VX
j0IL3g8CKEw+KiWVJM9HdLaDEz9fYtHBO8UHhKDDE94O9yxScIvB+GAhN4YlTtrE
z65VJkSCEw+3vH6XcrrkF2aEnB20jeEGiV5puO2cPoJpgcg3ic8sMVEfa/Z1qwqa
KCkj2XI28wBCIovCV+AfBhpvW0o8eVFbt4ESodLTmwjUvU+m8zxky/9cjO5kyLE=
=kgug
-END PGP SIGNATURE-
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://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] Transparent proxy with Peek and Splice feature.

[Amos Jeffries]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 26/11/2014 7:22 a.m., Vadim Rogoziansky wrote:
> Hello All.
> 
> My goal is to do ssl bumping in transparent proxy mode with domain 
> exclude possibility. Let me tell you about squid's strange
> behaviour when I'm trying to do it.
> 
> In browsers it says something like this: /This server could not
> prove that it is www.ukr.net; its security certificate is
> from212.42.76.253. This may be caused by a misconfiguration or an
> attacker intercepting your connection.// 
> //NET::ERR_CERT_COMMON_NAME_INVALID// //Subject: 212.42.76.253// / 
> Looks like squid takes the CN from the certificate as IP address of
> the destination domain.

Squid takes the IP address from the TCP packet. Which is all that is
available in NAT intercepted traffic at bumping step #1.

The ACLs you have therefore determine that "bump" action is to happen.
Correct?

The cert details are therefore mimic'ed from what gets delivered by
the server.

It may be that the server is depending on SNI to generate its own
cert, but since Squid deos not have that domain name already an
IP-based cert comes back.

It may also be that some ISP upstream of you is bumping the encryption
with client-first method.



> But, everything works smoothly when I use proxy in non transparent
> mode and put it to the browser directly .

In which case the browser sends domain name to the proxy in its
CONNECT message starting the HTTPS. The possible results are very
different.

Amos

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUdZ5sAAoJELJo5wb/XPRj0qIIANBjuFvq45hPmcaj/NYL6bza
7ttt5Gn+tn8E5KH7T4wfQhUXr91UIsYWfOswfnVAAlBevIO/iFVoDN5hAOveuhIl
ra/0eGti1EpZ3LHJiAqmo0mHsrz3v9+PAduVrXgUJLyYDiM0xctg0nRhj2u166VX
j0IL3g8CKEw+KiWVJM9HdLaDEz9fYtHBO8UHhKDDE94O9yxScIvB+GAhN4YlTtrE
z65VJkSCEw+3vH6XcrrkF2aEnB20jeEGiV5puO2cPoJpgcg3ic8sMVEfa/Z1qwqa
KCkj2XI28wBCIovCV+AfBhpvW0o8eVFbt4ESodLTmwjUvU+m8zxky/9cjO5kyLE=
=kgug
-END PGP SIGNATURE-
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] transparent proxy https and self signed certificate error

[Robert Watson]

Ok, finally got the certificate installed properly and can proxy some https
sites (gmail, google) but I get an error when going to a bank website.
NET::ERR_CERT_COMMON_NAME_INVALID
when I created the certificate, I purposefully left the common name blank
as per several articles on ssl_bump.  So I'm assuming it's complaining
about the CN generated by squid/ssl_bump?

On Mon, Oct 13, 2014 at 9:22 AM, Robert Watson 
wrote:

> Ok, finally got the certificate installed properly and can proxy some
> https sites (gmail, google) but I get an error when going to a bank
> website.
> NET::ERR_CERT_COMMON_NAME_INVALID
> when I created the certificate, I purposefully left the common name blank
> as per several articles on ssl_bump.  So I'm assuming it's complaining
> about the CN generated by squid/ssl_bump?
>
>
>
> On Mon, Oct 6, 2014 at 12:39 AM, Amos Jeffries 
> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 6/10/2014 4:24 p.m., Robert Watson wrote:
>> > still trying to get this working.  To eliminate the self signed
>> > certificate issue, I got a official signed certificate from
>> > Starfield Tech. LLC. They've sent two certifcates but I'm unsure
>> > how to use these certificates since the ssl_bump parameters only
>> > have one certificate as a parameter
>>
>> The CA is very unlikely to be issuing you certificates capable of use
>> in Squid in the way intended. It is illegal for a trusted root CA to
>> do so in the country they are registered. Besides that it is downright
>> foolish for them to give up their trust reputation. Look at what
>> happened to DigiNotar.
>>
>> The point of self-signed is that _your Squid_ is the root CA signer.
>>
>> The ssl-bump feature in current Squid makes parameter cert= take the
>> self-signed CA certificate in PEM format. Squid generates the rest of
>> the certificte chain as necessary.
>>
>> >
>> > On Sun, Oct 5, 2014 at 8:52 AM, Eliezer Croitoru wrote:
>> >
>> > On 10/05/2014 01:22 PM, Amos Jeffries wrote:
>>  MSIE 11 seems to be growing in popularity for some reason
>>  ;-)
>> 
>>  Amos
>> >
>> > And Still there is:
>> > http://bugs.squid-cache.org/show_bug.cgi?id=4115
>> >
>> > For now I am using ssl_crtd of 3.4.5 for google ssl bump to work.
>> >
>> > Eliezer
>>
>> Amos
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v2.0.22 (MingW32)
>>
>> iQEcBAEBAgAGBQJUMkdGAAoJELJo5wb/XPRjygMH/Rk0EYwCgluL1YCWNa8cTZHN
>> RkPNY1fTbe7U0ioB7J69KTJ07XH8sy0w9bChB5s/siodi3WD8ogZ3VdtEYxcqjf1
>> 9yhb771Il3IiVaAiuF62FHWTEHjwHwTcBVR7/cDxigPW2VuSyyhZsdA8ayl1ZUXO
>> jW44IH5g0Sja7KVJAfS67AANG4Sp4vMh1rGdXpbP8Bq8QGposL3viGh51z3k6/OP
>> Dok8oVIsIluICLc8sLAKJbJwaBYSh0SLBrnNUv0Yl6+MtAFNfViXJGa3OfRG5ucQ
>> aTS9Be4vzJthVdV1+tTtqubCvjrYB7PqQcfL9VzA4UlvQovgPDAnVMO074Kyjug=
>> =k3K8
>> -END PGP SIGNATURE-
>> ___
>> squid-users mailing list
>> squid-users@lists.squid-cache.org
>> http://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] transparent proxy https and self signed certificate error

[Amos Jeffries]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/10/2014 4:24 p.m., Robert Watson wrote:
> still trying to get this working.  To eliminate the self signed
> certificate issue, I got a official signed certificate from
> Starfield Tech. LLC. They've sent two certifcates but I'm unsure
> how to use these certificates since the ssl_bump parameters only
> have one certificate as a parameter

The CA is very unlikely to be issuing you certificates capable of use
in Squid in the way intended. It is illegal for a trusted root CA to
do so in the country they are registered. Besides that it is downright
foolish for them to give up their trust reputation. Look at what
happened to DigiNotar.

The point of self-signed is that _your Squid_ is the root CA signer.

The ssl-bump feature in current Squid makes parameter cert= take the
self-signed CA certificate in PEM format. Squid generates the rest of
the certificte chain as necessary.

> 
> On Sun, Oct 5, 2014 at 8:52 AM, Eliezer Croitoru wrote:
> 
> On 10/05/2014 01:22 PM, Amos Jeffries wrote:
 MSIE 11 seems to be growing in popularity for some reason
 ;-)
 
 Amos
> 
> And Still there is: 
> http://bugs.squid-cache.org/show_bug.cgi?id=4115
> 
> For now I am using ssl_crtd of 3.4.5 for google ssl bump to work.
> 
> Eliezer

Amos
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUMkdGAAoJELJo5wb/XPRjygMH/Rk0EYwCgluL1YCWNa8cTZHN
RkPNY1fTbe7U0ioB7J69KTJ07XH8sy0w9bChB5s/siodi3WD8ogZ3VdtEYxcqjf1
9yhb771Il3IiVaAiuF62FHWTEHjwHwTcBVR7/cDxigPW2VuSyyhZsdA8ayl1ZUXO
jW44IH5g0Sja7KVJAfS67AANG4Sp4vMh1rGdXpbP8Bq8QGposL3viGh51z3k6/OP
Dok8oVIsIluICLc8sLAKJbJwaBYSh0SLBrnNUv0Yl6+MtAFNfViXJGa3OfRG5ucQ
aTS9Be4vzJthVdV1+tTtqubCvjrYB7PqQcfL9VzA4UlvQovgPDAnVMO074Kyjug=
=k3K8
-END PGP SIGNATURE-
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] transparent proxy https and self signed certificate error

[Robert Watson]

still trying to get this working.  To eliminate the self signed certificate
issue, I got a official signed certificate from Starfield Tech. LLC.
They've sent two certifcates but I'm unsure how to use these certificates
since the ssl_bump parameters only have one certificate as a parameter

On Sun, Oct 5, 2014 at 8:52 AM, Eliezer Croitoru 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/05/2014 01:22 PM, Amos Jeffries wrote:
> > MSIE 11 seems to be growing in popularity for some reason ;-)
> >
> > Amos
>
> And Still there is:
> http://bugs.squid-cache.org/show_bug.cgi?id=4115
>
> For now I am using ssl_crtd of 3.4.5 for google ssl bump to work.
>
> Eliezer
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJUMWk4AAoJENxnfXtQ8ZQUWq4H/3f7taU+CyIxIMf9/itYdcF8
> IxFyaYalAtEMsiqpslabtLOSKx1Mao9188JBSdt/6A2T+LhWFCZ1hrRHcOPRwMl6
> sR5ZqBVBj0kxJc1wP/XfICcCv7OUZvYj7f0QLSLaOWcQfCO5YqdiIuZX6Pvo+zDT
> EvJTpNd3NVDiss18UB1RL/hlGMidKLsq5WxgooFo8AXpyGI1aqzw9LMAWFYmY2x6
> M19c/hR/dT0U0b+9JZMaqg6doOzx21UeZq+JVqqn06LV/WDUuoLKrI72A3gJlrGq
> VHDcmIKNXGW+0zpihiNful+vUwYxS5lHVy3obgtsMeBFy8UgWaAr+C0/3oOoimA=
> =wD9N
> -END PGP SIGNATURE-
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://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] transparent proxy https and self signed certificate error

[Eliezer Croitoru]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/05/2014 01:22 PM, Amos Jeffries wrote:
> MSIE 11 seems to be growing in popularity for some reason ;-)
> 
> Amos

And Still there is:
http://bugs.squid-cache.org/show_bug.cgi?id=4115

For now I am using ssl_crtd of 3.4.5 for google ssl bump to work.

Eliezer
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUMWk4AAoJENxnfXtQ8ZQUWq4H/3f7taU+CyIxIMf9/itYdcF8
IxFyaYalAtEMsiqpslabtLOSKx1Mao9188JBSdt/6A2T+LhWFCZ1hrRHcOPRwMl6
sR5ZqBVBj0kxJc1wP/XfICcCv7OUZvYj7f0QLSLaOWcQfCO5YqdiIuZX6Pvo+zDT
EvJTpNd3NVDiss18UB1RL/hlGMidKLsq5WxgooFo8AXpyGI1aqzw9LMAWFYmY2x6
M19c/hR/dT0U0b+9JZMaqg6doOzx21UeZq+JVqqn06LV/WDUuoLKrI72A3gJlrGq
VHDcmIKNXGW+0zpihiNful+vUwYxS5lHVy3obgtsMeBFy8UgWaAr+C0/3oOoimA=
=wD9N
-END PGP SIGNATURE-
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] transparent proxy https and self signed certificate error

[Rafael Akchurin]

Hello Robert,

Just my two cents - if you remove or comment out the
  sslproxy_cert_error allow all
  sslproxy_flags DONT_VERIFY_PEER

from squid config - may it be that squid starts complaining - "cannot get cert 
issues locally" on the google sites?

Rafael.

From: Robert Watson mailto:rob...@gillecaluim.com>>
Date: Sunday 5 October 2014 02:29
To: 
"squid-users@lists.squid-cache.org" 
mailto:squid-users@lists.squid-cache.org>>
Subject: [squid-users] transparent proxy https and self signed certificate error

using squid 3.4.8, compiled from source with ./configure flags 
--enable-icap-client --enable-ssl --enable-ssl-crtd
configured iptables for transparent proxy (redirect 80 to 3128) and everything 
works fine

configured iptables for transparent proxy (redirect 443 to 3127) but can't get 
transparent proxy for https to work
my squid.conf
...
# Squid https port
https_port 3127 intercept ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=4MB cert=/etc/squid/ssl_cert/XXX.pem
acl broken_sites dstdomain .example.com
ssl_bump none localhost
ssl_bump none broken_sites
ssl_bump server-first all
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER
sslcrtd_program /usr/lib/squid/ssl_crtd -s /var/lib/squid/ssl_db -M 4MB
sslcrtd_children 32 startup=5 idle=1

when visiting google (or any other https site) chrome complains
NET::ERR_CERT_AUTHORITY_INVALID
I tried using internet explorer as admin and imported the self signed 
certificate but that hasn't helped

can anyone please with how to debug this
thanks, Robert

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

Re: [squid-users] transparent proxy https and self signed certificate error

[Amos Jeffries]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 5/10/2014 7:30 p.m., Jason Haar wrote:
> On 05/10/14 18:44, Amos Jeffries wrote:
>> PS. Google with Chrome appear these days to be the champions of 
>> unbreakable TLS, their software is continually being updated to 
>> use/invent new TLS features that close loopholes in TLS design
>> which allow ssl-bump to take place. What worked last month has no
>> guarantee of working today, same again next month.
> That can't be right? I mean, sslbump doesn't rely on any "bugs" -
> it is simply a CA and so any browser that thinks it's a CA should
> be happy going to any https website using appropriate certs signed
> by that CA?

The CA system itself is the design flaw. No I would not go so far as
to say "bug" (thats code) but "loophole" and "flaw" are more
appropriate for a system design problem.

The intention and design of TLS/SSL is to prevent third-party
intermediaries (is Squid) inntercepting communications (is ssl-bump)
and looking at what the traffic inside is. Anything that lets a third
party access is by definintion a flaw in the TLS protocol design.


> 
> I know Chrome has *cert pinning* (ie they hardwired the CAs that
> Google knows *.google.com uses into  Chrome), but that isn't a
> "loophole".
> 

Yes, cert pinning, HSTS, hard coded google.com CA certificates ...
whatever they can think of next.

> sslbump seems to work as well as can be expected. But pinning also 
> appears to be growing in stature (Firefox now does it too), so
> there are less and less sites that sslbump can work on. I wanted to
> use sslbump so that we could run AV and filtering on https links,
> but pinning means our "exclude list" of https sites is getting
> larger and larger - and includes Cloud providers the badguys are
> housing their malware on - which means our AV still can't catch it
> :-(
> 

MSIE 11 seems to be growing in popularity for some reason ;-)

Amos

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUMRvXAAoJELJo5wb/XPRjJIYIAJHx4z+EVNklXjSIqdmOuqeu
6ZHajLCDm/yGt6+JyLvJARNkVtfL2buiw4PbgLqJ+mHWpTFiU0Jvat3JX1vVPmMx
IgpgmMVTV185Rv12V3CrFFVNAfAgqVjgCgP5tYiJ6idAzOpLUaWfEHNzMtrCmg+s
/yNr9may7zbi8HxUw22Egjj565Dfp0eB3zGGGNiUunrQ9CkI/hBHtWAoMTKk6oFE
I923uzi6Kmmuidmw+9WFM38VsKHslspu3/celZT7uVj2QrqDYzrh7Li5dLbL42W3
/WcJu90PJngUkY9E2RFcJoq7cppFR6stnO9sytuSS1lhOCY4MRTUCrYrCy1y2YU=
=d/33
-END PGP SIGNATURE-
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] transparent proxy https and self signed certificate error

[Jason Haar]

On 05/10/14 18:44, Amos Jeffries wrote:
> PS. Google with Chrome appear these days to be the champions of
> unbreakable TLS, their software is continually being updated to
> use/invent new TLS features that close loopholes in TLS design which
> allow ssl-bump to take place. What worked last month has no guarantee
> of working today, same again next month.
That can't be right? I mean, sslbump doesn't rely on any "bugs" - it is
simply a CA and so any browser that thinks it's a CA should be happy
going to any https website using appropriate certs signed by that CA?

I know Chrome has *cert pinning* (ie they hardwired the CAs that Google
knows *.google.com uses into  Chrome), but that isn't a "loophole".

sslbump seems to work as well as can be expected. But pinning also
appears to be growing in stature (Firefox now does it too), so there are
less and less sites that sslbump can work on. I wanted to use sslbump so
that we could run AV and filtering on https links, but pinning means our
"exclude list" of https sites is getting larger and larger - and
includes Cloud providers the badguys are housing their malware on -
which means our AV still can't catch it  :-(


-- 
Cheers

Jason Haar
Corporate Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1


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

Re: [squid-users] transparent proxy https and self signed certificate error

[Amos Jeffries]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 5/10/2014 1:29 p.m., Robert Watson wrote:
> using squid 3.4.8, compiled from source with ./configure flags 
> --enable-icap-client --enable-ssl --enable-ssl-crtd configured
> iptables for transparent proxy (redirect 80 to 3128) and everything
> works fine
> 
> configured iptables for transparent proxy (redirect 443 to 3127)
> but can't get transparent proxy for https to work my squid.conf 
> ... # Squid https port https_port 3127 intercept ssl-bump
> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
> cert=/etc/squid/ssl_cert/XXX.pem acl broken_sites dstdomain
> .example.com ssl_bump none localhost ssl_bump none broken_sites 
> ssl_bump server-first all sslproxy_cert_error allow all 
> sslproxy_flags DONT_VERIFY_PEER sslcrtd_program
> /usr/lib/squid/ssl_crtd -s /var/lib/squid/ssl_db -M 4MB 
> sslcrtd_children 32 startup=5 idle=1
> 
> when visiting google (or any other https site) chrome complains 
> NET::ERR_CERT_AUTHORITY_INVALID I tried using internet explorer as
> admin and imported the self signed certificate but that hasn't
> helped
> 
> can anyone please with how to debug this thanks, Robert

To debug you will need a packet capture with full packet bodies
(tcpdump -s 0) of the TCP connection between browser and Squid, and
the connection between Squid and server.
Wireshark should be able to decrypt the TLS/SSL handshakes to see what
differences or corruption is happening.


FYI: When testing be sure to clear/empty the ssl_crtd database if any
changes are made to CA keys.



PS. Google with Chrome appear these days to be the champions of
unbreakable TLS, their software is continually being updated to
use/invent new TLS features that close loopholes in TLS design which
allow ssl-bump to take place. What worked last month has no guarantee
of working today, same again next month.

Amos

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUMNrEAAoJELJo5wb/XPRj7QAIAMVZ5SOc+X8vWlMdbgyNhNJR
k//TmLRMdwZ1qxFBHTF3t+I7JVua2b+DDp0fU6Ubq6WvoARNBQGPQdI0XfOtrnLQ
3lsBCkU8NZuXt2LeoKG6eNPaNyuhom7HeFzmwELgM4SuASxbO4mpBxET8Tg1XYwQ
VdSruqwx0hwhb5g4yeXWEIflkILc1A5cTAAbNGXIHpWbqMmwvnav5KWCfDhesHEU
CdxuyZJnUZwv/uRYSaiiYebUECTS/Zl8JkGvCXe5zheLwT2Wcor3urUXIK3gPToz
dy8FJ7lRGSSIJNkiQO4iNwI28vYkJHP2u3yFMFOdu4r/jN7WRgaY2LSpaQF+pqc=
=teuE
-END PGP SIGNATURE-
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Transparent proxy with squid and Dansguardian

[Amos Jeffries]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Please post a new thread email to the list instead of replying to an
existing topic. This has nothing to do with YouTube access control.


On 1/10/2014 11:23 p.m., Darren B. wrote:
> 
> HI
> 
> I am trying to set up a router that allows a group of devices on a 
> network to access the internet via Dansguardian and squid.
> 
> I am setting it up as a transparent proxy and locking down the
> ports with IPtables.
> 
> I am using IPtables to redirect connections on port 80 from the
> client and remap them to 8080 for dansguardian, dans is then set up
> to talk to squid on 127.0.0.1:3128
> 
> the iptables rules are
> 
> iptables -A PREROUTING -p tcp -m tcp -i eth1 --dport 80 -j
> REDIRECT --to-ports 8080 iptables -A POSTROUTING -j MASQUERADE
> 
> if I set the rule above to REDIRECT to 3128, the cache works as 
> expected. If I set it above, I can see traffic in DG and in the
> cache log of squid but the target IF address is stripped out and I
> seem to be getting a forwarding loop.
> 
> I am not sure what is going on but it seems that Dansguardian is 
> rewriting the target address and getting squid to loop back on
> itself.

DG is opening a regular TCP connection from itself (127.0.0.1:*) to
Squid (127.0.0.1:3128). Nothing Special.

> 
> All the various versions are current to ubuntu 14.04 although the 
> dansguardian is a little old in this distro.
> 
> Any pointers would be greatly appreciated.

Okay, some pointers...

 * REDIRECT is NAT interception.

 * You have DG configured to use Squid port 3128 *without* NAT between
them.

 * You configured Squid to receive NAT traffic on port 3128.

 * You configured Squid to receive expicitly configured clients (like
DG) on port 3129.

 * you must only send the configured type of traffic to a Squid port.

Amos

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUK+EoAAoJELJo5wb/XPRjFWcH/1v6l48h2TuDydVuk9p87BMs
NZ8IrbcMtkqmNaIoWJ8KapvpFERBDyZVVQ54TX1iVPOUh4nHPskzzc7iZFXK1P5h
F+oIqecgaQ+KwbdIRn0YJF5w0XppSiH1aRX3dmbwIHI3ghH7cca7Nj6txHdhyaq0
udlEp+1mteyy+7gbGJTNVR4XCqDPwVfgBzuvMtQFI2C6yqf7OcxqibAW/J9SYp5z
XM/Ap8tw7Q2xNC9a8BI/AURb4RkcelMX/iQ1G41oMCKcKEW2BjfOe6AVe0UbT8AD
jNDkhsmLqgOHfubiMhRiZHkayy1qcJLapNuyi5XkYcASD1rTtuqKoBhumqiJFrE=
=w4j+
-END PGP SIGNATURE-
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users