Re: myport and myip differences between Squid 2.7 and 3.1 when running in intercept mode

2009-09-18 Thread Amos Jeffries 

James Brotchie wrote:

G'day,

I'm curious about a change to the transparent/interception behaviour
between Squid versions 2.7 and 3.1.

I'm using a iptables NAT redirect to send all tcp traffic with dst
port 80 on the FORWARD chain to port 60080 and in my squid.conf I have

http_port 60080 transparent for Squid 2.7
http_port 60080 intercept for Squid 3.1

I also have the following ACL
acl intercepted myport 60080

Squid is running on 192.168.0.112 and a box with 192.168.0.112 as its
gateway is trying to access 64.191.203.30:80.

On Squid 2.7 the intercepted acl matches whilst in 3.1 it doesn't.

Digging deeper into the Squid 3.1 source it seems that if a http_port
is set to intercept then the me member of ConnStateData, which is
normally the proxy's ip and listening port, is replaced by the pre-NAT
destination ip and port.

client_side.cc: 2959
if (port-intercepted || port-spoof_client_ip) {
IpAddress client, dst;

if (IpInterceptor.NatLookup(fd, me, peer, client, dst) == 0) {
result-me = client;
result-peer = dst;
result-transparent(true);
}
}

Thus it seems, for the scenario above, in the Squid 2.7 case
myport = 60080, myip = 192.168.0.112

yet in the 3.1 case
myport = 80, myip = 64.191.203.30

Is this the desired behaviour, and if so, why did this change
somewhere between 2.7 and 3.1?

Cheers,
James Brotchie


Hmm. Some of the lookups require it and some break if it is. There is a 
bit of cleanup here that will need consideration:


  The me field has very ambiguous meaning and inconsistent use 
between all modes of Squid. myport and myip tests thus only work 
reliably in normal forward and reverse modes.


Meanwhile the http_port now has a name= option for testing with 
myportname ACL.


Amos
--
Please be using
  Current Stable Squid 2.7.STABLE6 or 3.0.STABLE19
  Current Beta Squid 3.1.0.13

Re: myport and myip differences between Squid 2.7 and 3.1 when running in intercept mode

2009-09-18 Thread Henrik Nordstrom 
fre 2009-09-18 klockan 11:13 +1000 skrev James Brotchie:

 On Squid 2.7 the intercepted acl matches whilst in 3.1 it doesn't.

In 2.7 the myport and myip acls are very unreliable in interception
mode. Depends on the request received if these are the local endpoint or
the original destination enpoint..

 Digging deeper into the Squid 3.1 source it seems that if a http_port
 is set to intercept then the me member of ConnStateData, which is
 normally the proxy's ip and listening port, is replaced by the pre-NAT
 destination ip and port.

And in 2.7 it just sometimes are, i.e. when the original destnation is
required to resolve the request.

And on some OS:es it always are replaced, depends on how the original
destination information is given to Squid.

Regards
Henrik

myport and myip differences between Squid 2.7 and 3.1 when running in intercept mode

2009-09-17 Thread James Brotchie 
G'day,

I'm curious about a change to the transparent/interception behaviour
between Squid versions 2.7 and 3.1.

I'm using a iptables NAT redirect to send all tcp traffic with dst
port 80 on the FORWARD chain to port 60080 and in my squid.conf I have

http_port 60080 transparent for Squid 2.7
http_port 60080 intercept for Squid 3.1

I also have the following ACL
acl intercepted myport 60080

Squid is running on 192.168.0.112 and a box with 192.168.0.112 as its
gateway is trying to access 64.191.203.30:80.

On Squid 2.7 the intercepted acl matches whilst in 3.1 it doesn't.

Digging deeper into the Squid 3.1 source it seems that if a http_port
is set to intercept then the me member of ConnStateData, which is
normally the proxy's ip and listening port, is replaced by the pre-NAT
destination ip and port.

client_side.cc: 2959
    if (port-intercepted || port-spoof_client_ip) {
    IpAddress client, dst;

    if (IpInterceptor.NatLookup(fd, me, peer, client, dst) == 0) {
    result-me = client;
    result-peer = dst;
    result-transparent(true);
    }
    }

Thus it seems, for the scenario above, in the Squid 2.7 case
myport = 60080, myip = 192.168.0.112

yet in the 3.1 case
myport = 80, myip = 64.191.203.30

Is this the desired behaviour, and if so, why did this change
somewhere between 2.7 and 3.1?

Cheers,
James Brotchie