[squid-users] Re: SQUID in TPROXY - do not resolve
hi amos , is there a method that let squid force its dns reply and ignore the client dns reply ??? = i mean if client x got 1.1.1.1 and squid got 2.2.2.2 i want client to go to 2.2.2.2 not to 1.1.1.1 = regards - Dr.x -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/SQUID-in-TPROXY-do-not-resolve-tp4662819p4663009.html Sent from the Squid - Users mailing list archive at Nabble.com.
Re: [squid-users] Re: SQUID in TPROXY - do not resolve
On 30/10/2013 8:28 p.m., Dr.x wrote: hi amos , is there a method that let squid force its dns reply and ignore the client dns reply ??? = i mean if client x got 1.1.1.1 and squid got 2.2.2.2 i want client to go to 2.2.2.2 not to 1.1.1.1 = Which one is the real server? How do you know the client was wrong about where *they* were contacting? * some clients base connections on details other than DNS A and records. * some services present special IP address contacts only to registered clients (ie Google DNS). This may be Squid OR the client. The only case where it turns out to actually be safe is when the DNS lookup for Squid and client match. You can set client_dst_passthru directive to 'off' for those cases. Amos
[squid-users] Re: SQUID in TPROXY - do not resolve
hi amos , my request is , i dont want to install squidguar don my machine , i want to use dns of squid except of that i mean i want to direct squid to norton dns , and in this case if the dns of clients and squid didnt match , the website or the request of client must be blocked ! iive tried : client_dst_passthru off host_verify_strict on but no luck , the client still can bypass the webfiltering i mean it is supposed that client visit the destination ip result from squid dns resovling , not the ip result from its resolving !! but uptill now , althoug i put the two directives above, the client still visit the ip resulted from its dns resolving ! with to clarify regards - Dr.x -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/SQUID-in-TPROXY-do-not-resolve-tp4662819p4663024.html Sent from the Squid - Users mailing list archive at Nabble.com.
Re: [squid-users] Re: SQUID in TPROXY - do not resolve
On 31/10/2013 7:52 a.m., Dr.x wrote: hi amos , my request is , i dont want to install squidguar don my machine , i want to use dns of squid except of that i mean i want to direct squid to norton dns , and in this case if the dns of clients and squid didnt match , the website or the request of client must be blocked ! iive tried : client_dst_passthru off host_verify_strict on but no luck , the client still can bypass the webfiltering ?? with host_verify_strict on any client who fails the verification gets an error page. They are not permitted through by Squid. Not even to receive HITs. Are you certain these clients were using HTTP and not using some other protocol such as SPDY, WebSockets, or CoAP? or somehow bypassing the interception itself? i mean it is supposed that client visit the destination ip result from squid dns resovling , not the ip result from its resolving !! but uptill now , althoug i put the two directives above, the client still visit the ip resulted from its dns resolving ! client_dst_passthru off only means that Squid is *allowed* to use other IPs if it needs to, it does not have to (and what happens when the site only has 1 IP anyway?). To improve transparency and reliability of any assumptions the client application is making Squid uses it anyway after verification. Note that for verify to succeed Squid MUST have resolved that IP as one of the hosts legitimate IPs - so it was probably going to be used by Squid and called DIRECT anyway. The only difference between ORIGINAL_DST and DIRECT when verify succeeds is the risk of client-server application level systems breaking (none when ORIGINAL_DST is used, some small risk when DIRECT is used). Amos
[squid-users] Re: SQUID in TPROXY - do not resolve
@plamen , regards to 1st discussion now i tried trpoxy squid i pointed squid to dns1 and put on my pc dns2 my pc resolved the site aaa.com with 1.1.1.1 and squid resolved aaa.com with 2.2.2.2 but my pc see the site with 1.1.1.1 not with 2.2.2.2 ??? why ? shouldn't my pc see the site with 2.2.2. because of tproxy ??? wish to make sure to me - Dr.x -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/SQUID-in-TPROXY-do-not-resolve-tp4662819p4662965.html Sent from the Squid - Users mailing list archive at Nabble.com.
Re: [squid-users] Re: SQUID in TPROXY - do not resolve
On 28/10/2013 9:46 p.m., Ahmad wrote: @plamen , regards to 1st discussion now i tried trpoxy squid i pointed squid to dns1 and put on my pc dns2 my pc resolved the site aaa.com with 1.1.1.1 and squid resolved aaa.com with 2.2.2.2 but my pc see the site with 1.1.1.1 not with 2.2.2.2 ??? why ? shouldn't my pc see the site with 2.2.2. because of tproxy ??? No. Squid fetches from 1.1.1.1 same as the client wanted to get it from (transparent means same in and out). All that happens in this case is that Squid block caching because it cannot trust that 1.1.1.1 is authorized to be presenting content from 2.2.2.2. Amos
Re: [squid-users] Re: SQUID in TPROXY - do not resolve
On 25/10/2013 2:44 a.m., Plamen wrote: Amos Jeffries-2 wrote On 24/10/2013 6:44 a.m., Plamen wrote: Yes, this is one of the problems I'm also experiencing, the customer is using different DNS than the Squid, and he complains because he says - without your SQUID I can open web page, but with your SQUID it's not opening. Ah. So the real problem is Why is it not opening for Squid? The current releases of Squid *do* use the client provided destination IP. The DNS resolution is only to determine whether the response is cacheable and if alternative IPs may be tried as backup _if_ the client given one is unable to connect by Squid. Hi Amos, thanks for the valuable feedback. Do I need to do something specific to get this behavior of Squid where it uses the dst provided IP, like some directive in config has to be enabled or it is default behavior? This is default behaviour for squid-3.2 and later. In this scenario, what happens if the DNS servers configured in SQUID stop responding for some reason for some period of time (or they become unreachable), will the traffic continue to pass normally or the users will start getting errors and they will not be able to browse anymore? Traffic will pass to the client dst IP. There may be some small lag on the first request after DNS went out while Squid waits for the DNS response. But some delays are only to be expected when things on the network break. I will give you real life example that I'm trying to resolve. The ISP is having 2 Upstream providers. The SQUID is running in TPROXY mode, and the squidbox has an IP address from Upstream 1 and respectively uses this IP to contact DNS servers. When both upstream providers are working - everything is smooth in terms of HTTP traffic. When Upstream 1 goes down for some reason, for a period of time, the customers which are provisioned with IPs belonging to UPSTREAM 2 also get affected because the SQUID cannot do DNS lookups anymore. I'm trying to resolve this kind of issues. This kind of issue is best fixed via other means. For example; I use IPv6 private allocation fc00::/16 IP addressing for all my network internal traffic including the links between Squid and its DNS server. No matter which upstream is active (even with none) these connections and lookups will continue working so long as my own network remains stable. Another way is to configure an explicit address in udp_outgoing_address for Squid to use as its src IP on UDP packets (and thus DNS packets). This does the same thing for Squid-DNS traffic, but does not protect other internal-only traffic so I dont favour it as much as the IPv6 method. Amos
[squid-users] Re: SQUID in TPROXY - do not resolve
Amos Jeffries-2 wrote On 24/10/2013 6:44 a.m., Plamen wrote: Yes, this is one of the problems I'm also experiencing, the customer is using different DNS than the Squid, and he complains because he says - without your SQUID I can open web page, but with your SQUID it's not opening. Ah. So the real problem is Why is it not opening for Squid? The current releases of Squid *do* use the client provided destination IP. The DNS resolution is only to determine whether the response is cacheable and if alternative IPs may be tried as backup _if_ the client given one is unable to connect by Squid. Hi Amos, thanks for the valuable feedback. Do I need to do something specific to get this behavior of Squid where it uses the dst provided IP, like some directive in config has to be enabled or it is default behavior? In this scenario, what happens if the DNS servers configured in SQUID stop responding for some reason for some period of time (or they become unreachable), will the traffic continue to pass normally or the users will start getting errors and they will not be able to browse anymore? I will give you real life example that I'm trying to resolve. The ISP is having 2 Upstream providers. The SQUID is running in TPROXY mode, and the squidbox has an IP address from Upstream 1 and respectively uses this IP to contact DNS servers. When both upstream providers are working - everything is smooth in terms of HTTP traffic. When Upstream 1 goes down for some reason, for a period of time, the customers which are provisioned with IPs belonging to UPSTREAM 2 also get affected because the SQUID cannot do DNS lookups anymore. I'm trying to resolve this kind of issues. In such cases the caching part for the period of time when no DNS is available, doesn't really bother me but mostly we are looking for a way not to disturb the users of Upstream 2. Thanks in advance. -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/SQUID-in-TPROXY-do-not-resolve-tp4662819p4662852.html Sent from the Squid - Users mailing list archive at Nabble.com.
[squid-users] Re: SQUID in TPROXY - do not resolve
hi all , relative to dns , transparent proxy , tproxy , in this scenario the dns on client differ than dns confogured on squid !! assume client x reolved www.google.com with 1.1.1.1 and squid reolved www.google.com with 2.2.2.2 squid will find this an insecure , but my question is , will squid will let client visit 1.1.1.1 or squid will let client visit 2.2.2.2 ? i mean squid will use its resolving or the client resolving in this case ?? regards - Dr.x -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/SQUID-in-TPROXY-do-not-resolve-tp4662819p4662827.html Sent from the Squid - Users mailing list archive at Nabble.com.
[squid-users] Re: SQUID in TPROXY - do not resolve
Yes, this is one of the problems I'm also experiencing, the customer is using different DNS than the Squid, and he complains because he says - without your SQUID I can open web page, but with your SQUID it's not opening. Imagine network with 5 end subscribers and having to react on similar cases on daily basis... I am ready to sacrifice whatever benefits are there with DNS resolving done by SQUID to overcome the above mentioned problems. -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/SQUID-in-TPROXY-do-not-resolve-tp4662819p4662828.html Sent from the Squid - Users mailing list archive at Nabble.com.
[squid-users] Re: SQUID in TPROXY - do not resolve
HI Palmen , agian , in this case you have to play the role of owning DNS server , u should put dns server internal if u were an isp ! you have to give your clients the ip of dns which squid is pointing on , you solve the problem in my opinion , with tproxy , the dns verification form squid cant be stopped !!! i advise you to find a method to forward all dns trials that are not directed to ur dns server to ur dns internet server and in this case u can solve the problem this is just suggesttion and not sure if it is applicable im waiting other discussions regards - Dr.x -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/SQUID-in-TPROXY-do-not-resolve-tp4662819p4662829.html Sent from the Squid - Users mailing list archive at Nabble.com.
Re: [squid-users] Re: SQUID in TPROXY - do not resolve
On 24/10/2013 6:44 a.m., Plamen wrote: Yes, this is one of the problems I'm also experiencing, the customer is using different DNS than the Squid, and he complains because he says - without your SQUID I can open web page, but with your SQUID it's not opening. Ah. So the real problem is Why is it not opening for Squid? The current releases of Squid *do* use the client provided destination IP. The DNS resolution is only to determine whether the response is cacheable and if alternative IPs may be tried as backup _if_ the client given one is unable to connect by Squid. IME the usual causes of these complaints is one of: * routing external server SYNACK packets back to the subscribers machine instead of proxy * using the client/subscribers destination IP, even when it is not routable from Squid * the subscribers custom DNS is resolving a internal domain and their software is sending it globally where it cannot resolve * the destination genuinely has a network outage (subscribers failed to say _yesterday_ [or even last week] was when it worked without proxy) * HTTP headers like X-Forwarded-For with valid IPv6 address *crash* some ASP.NET services * destination advertises IPv6 addresses which are not responding * destination rejecting any contact through a proxy (security reasons usually) * proxy config rules rejecting the traffic but subscribers only stating wont work instead of proxy error page * ECN protocol differences between Squid box OS and subscribers machine OS, * TCP window scaling differences between Squid box OS and subscribers machine OS, Many reasons for dont work ... small details matter. wont connect implies more specifically that several of those reasons are more likely than others. Imagine network with 5 end subscribers and having to react on similar cases on daily basis... I am ready to sacrifice whatever benefits are there with DNS resolving done by SQUID to overcome the above mentioned problems. Imagine one of them fetched http://google.com/ from a server setup to install malware then redirect to htttp://www.google.com/. If the traffic is not verified every single HIT for http://google.com/ from that point on would get the cached infection delivered, regardless of whether the other clients were actually going to google.com since the HIT means no upstream is used, just the cached malware. The only safe choices available are to verify or not to cache. Amos
