Dear Amos, Hi As the documentation suggests, I have used the following rules, but except the first one, others fail: ip rule add fwmark 1 lookup 100 ip -f inet route add local 0.0.0.0/0 dev lo table 100 ip -f inet route add local 0.0.0.0/0 dev eth0 table 10 Any ideas? Warm Regards, Ali Majdzadeh Kohbanani 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 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 > >> > >
