Re: myport and myip differences between Squid 2.7 and 3.1 when running in intercept mode
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
Re: myport and myip differences between Squid 2.7 and 3.1 when running in intercept mode
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
myport and myip differences between Squid 2.7 and 3.1 when running in intercept mode
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