Amos, Thanks for your reply. As you had depicted in the diagrams, I think you meant that the clients and the Squid box are both connected to the gateway through the switch, didn't you? If it is so, yes, they are connected, but the default gateway for the clients is set to the IP address of the Squid box. So, you mean we should insert a special firewall rule in our gateway in order to detect and bypass the Squid outward traffic by its MAC address, is that true? Does this method still preserves the clients' IP addresses? Sorry for my elementary questions and thanks in advance for your helpful notes. Warm Regards, Ali 2011/6/8 Ali Majdzadeh <ali.majdzadeh@xxxxxxxxx>: > Amos, > Thanks for your reply. As you had depicted in the diagrams, I think > you meant that the clients and the Squid box are both connected to the > gateway through the switch, didn't you? If it is so, yes, they are > connected, but the default gateway for the clients is set to the IP > address of the Squid box. > So, you mean we should insert a special firewall rule in our gateway > in order to detect and bypass the Squid outward traffic by its MAC > address, is that true? Does this method still preserves the clients' > IP addresses? > Sorry for my elementary questions and thanks in advance for your helpful notes. > > Warm Regards, > Ali > > 2011/6/8 Amos Jeffries <squid3@xxxxxxxxxxxxx>: >> On 08/06/11 22:53, Ali Majdzadeh wrote: >>> >>> Amos, >>> Hi >>> Thanks for your reply. The Squid box has only one NIC and it is >>> connected to the internet via it's default gateway, I think I should >>> have corrected our network diagram as follows: >>> Internet<-> Gateway<-> Squid<-> Clients >>> Does this configuration make any difference? >> >> That diagram is no different, but a 1-NIC squid box would be: >> >> Internet<->Gateway<->Clients. >> \<->Squid >> >> or: >> >> Internet<->Gateway<--switch-->Clients. >> \<->Squid >> >> >> That makes a difference. >> >> If you bump cache.log up to ALL,5 during a test connection. You may see >> traffic arrive but then hang while connecting out. >> >> If you do see that behaviour in cache.log, the problems is at the gateway >> end. It MUST be able to detect and bypass the Squid outward traffic by MAC >> address or tcp_outgoing_tos instead of IP address. >> >> Amos >> >>> Thanks again for your reply. I will try to reconfigure the whole >>> solution from scratch to find out where I go wrong. >>> >>> Warm Regards, >>> Ali Majdzadeh Kohbanani >>> >>> 2011/6/8 Amos Jeffries<squid3@xxxxxxxxxxxxx>: >>>> >>>> On 08/06/11 01:15, Ali Majdzadeh wrote: >>>>> >>>>> Amos, >>>>> The configuration is as follows: >>>>> Internet<-> Squid<-> Clients >>>>> >>>>> Would you please clarify what you mean by declaring "routing packets >>>>> to the squid box"? >>>> >>>> That the packets actually do get passed/routed through the squid box and >>>> not >>>> via some other possible route. >>>> >>>>> Does the above configuration conform to the >>>>> so-called declaration? >>>> >>>> If those are physical wires or even just logical routing table entries, >>>> yes >>>> it does. >>>> >>>>> If it is so, what should be done to solve the >>>>> issue? >>>> >>>> Your packet counter incrementing is a good sign that the ruting layer is >>>> okay. >>>> >>>>> Thanks again. >>>>> By the way, we have compiled libcap from source and it is the latest >>>>> version of the library. >>>> >>>> Okay. That should do :). >>>> >>>> >>>>> 2011/6/6 Ali Majdzadeh<ali.majdzadeh@xxxxxxxxx> >>>>>> >>>>>> Amos, >>>>>> Sorry, the packet counter increments, I made a mistake, but still no >>>>>> logs either in access.log nor in cache.log. >>>> >>>> >>>> Given that you have a recent libcap. That means we must suspect the >>>> kernel >>>> handling once TPROXY marks the packets. >>>> >>>> The "table 100" bit of the config has given a lot of people trouble. >>>> AFAIK >>>> "normally" you only have one such table entry and for TPROXY its internal >>>> to >>>> the kernel with the "lo" interface. BUT, some people have had to >>>> configure >>>> other interfaces to get it working. >>>> >>>> Try to add a table 100 (or whatever you called it) entry for each NIC the >>>> box has. If your kernel accepts them check access.log again. >>>> >>>> If your kernel denies multiple tables, erase the existing one and try >>>> creating one for each NIC. Repeating until you find one that works. >>>> >>>> OR, if that still fails. We have to get help from Balabit and/or >>>> Netfilter >>>> and figure WTF is happening. >>>> >>>> Amos >>>> >>>>>> >>>>>> Warm Regards, >>>>>> Ali Majdzadeh Kohbanani >>>>>> >>>>>> 2011/6/6 Ali Majdzadeh<ali.majdzadeh@xxxxxxxxx>: >>>>>>> >>>>>>> Amos, >>>>>>> Hi >>>>>>> The packet counter on -j TPROXY does not increment. So, why clients >>>>>>> are able to surf the web? >>>>>>> >>>>>>> Warm Regards, >>>>>>> Ali Majdzadeh Kohbanani >>>>>>> >>>>>>> 2011/6/6 Ali Majdzadeh<ali.majdzadeh@xxxxxxxxx> >>>>>>>> >>>>>>>> Amos, >>>>>>>> Hi >>>>>>>> Thanks for your reply. Ragarding the documentation, I have inserted >>>>>>>> the following routing rules: >>>>>>>> ip rule add fwmark 1 lookup 100 >>>>>>>> ip route add local 0.0.0.0/0 dev lo table 100 >>>>>>>> Now, access.log is populated with proper logs, but clients can not >>>>>>>> surf the web, I mean the proxy server is unable to forward http >>>>>>>> responses to clients' browsers. When the client enters for example >>>>>>>> www.google.com, the connection to the http server is established but >>>>>>>> the process halts at Waiting for www.google.com and after a while >>>>>>>> Squid reports the unablility to retreive the requested URL. >>>>>>>> By the way, we have disabled selinux. >>>>>>>> Any ideas? >>>>>>>> >>>>>>>> Warm Regards, >>>>>>>> Ali Majdzadeh Kohbanani >>>>>>>> >>>>>>>> 2011/6/6 Amos Jeffries<squid3@xxxxxxxxxxxxx>: >>>>>>>>> >>>>>>>>> On 06/06/11 06:32, Ali Majdzadeh wrote: >>>>>>>>>> >>>>>>>>>> Hello All, >>>>>>>>>> I have setup the following configuration: >>>>>>>>>> Squid (3.1.12) (--enable-linux-netfilter passed as the one and only >>>>>>>>>> configure option) >>>>>>>>>> Kernel (2.6.38.3) >>>>>>>>>> iptables (1.4.11) >>>>>>>>>> >>>>>>>>>> I have added the following two directives in squid.conf: >>>>>>>>>> http_port 3128 >>>>>>>>>> http_port 3129 tproxy >>>>>>>>>> >>>>>>>>>> Also, I have configured iptables with the following rules: >>>>>>>>>> iptables -t mangle -N DIVERT >>>>>>>>>> iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT >>>>>>>>>> iptables -t mangle -A DIVERT -j MARK --set-mark 1 >>>>>>>>>> iptables -t mangle -A DIVERT -j ACCEPT >>>>>>>>>> iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY >>>>>>>>>> --tproxy-mark 0x1/0x1 --on-port 3129 >>>>>>>>>> >>>>>>>>>> Everything work as expected, I mean, the users can surf the web and >>>>>>>>>> the proxy server is transparent. The problem is that actually there >>>>>>>>>> is >>>>>>>>>> no caching. I mean, both cache.log and access.log files are empty. >>>>>>>>>> On >>>>>>>>> >>>>>>>>> That would be transparency to the point of not going through the >>>>>>>>> proxy. >>>>>>>>> access.log should have entries for each request. >>>>>>>>> >>>>>>>>>> the other hand, if I manually set the proxy configuration in >>>>>>>>>> clients' >>>>>>>>>> browsers (the IP address of the squid server and port number 3128) >>>>>>>>>> everything is OK; the log files are incremented and objects are >>>>>>>>>> cached. >>>>>>>>>> >>>>>>>>>> Have anyone faced the same issue? >>>>>>>>> >>>>>>>>> Some. Its usually boiled down to missing out some details omitted. >>>>>>>>> building >>>>>>>>> against libcap2 or routing packets to the squid box for example. >>>>>>>>> >>>>>>>>> Are the packet counters on that -j TPROXY rule showing captures? >>>>>>>>> >>>>>>>>> Did you follow the rest of the feature config? >>>>>>>>> ie the special sub-routing table? OS packet filtering toggles? >>>>>>>>> selinux >>>>>>>>> updated to allow tproxy? >>>>>>>>> >>>>>>>>> Is this box even routing or bridging port 80 traffic for the >>>>>>>>> network? >>>>>>>>> >>>>>>>>> Amos >>>>>>>>> -- >>>>>>>>> Please be using >>>>>>>>> Current Stable Squid 2.7.STABLE9 or 3.1.12 >>>>>>>>> Beta testers wanted for 3.2.0.8 and 3.1.12.2 >>>>>>>>> >>>>>>> >>>> >>>> >>>> -- >>>> Please be using >>>> Current Stable Squid 2.7.STABLE9 or 3.1.12 >>>> Beta testers wanted for 3.2.0.8 and 3.1.12.2 >>>> >> >> >> -- >> Please be using >> Current Stable Squid 2.7.STABLE9 or 3.1.12 >> Beta testers wanted for 3.2.0.8 and 3.1.12.2 >> >
