Hey Peter,
Was tested more in depth inside CentOS 6.5.
SELINUX enforcing must be down unless there is strict rules that allows
the usage of tproxy.
To test it and make sure it works in the basic level you can add a
"cache_peer" with the option "no-tproxy".
It will allow you to see that the basic level of interception is being
done and the next steps is the network level which are very important
and can be very delicate.
I have used 6.5 base kernel and ELREPO-lt kernel (3.10.X) and both works
fine.
I would not run to build the whole network infrastructure internals to
test it since there was not changes in squid that should reflect any
issue that you are talking about.
(squid 3.4.2 tested with tproxy basics)
Output of: http://www1.ngtech.co.il/ip.php
"Your Proxy IP address is : 192.168.11.100, 192.168.10.108(via
192.168.10.109)
Your country :
Mozilla/5.0 (Windows NT 5.1; rv:26.0) Gecko/20100101 Firefox/26.0"
Eliezer
On 29/01/14 11:59, Peter Warasin wrote:
Hi Madhav
Thank you for answers.
Well, I can bind squid on port 18080, that's not the problem, but
packets don't arrive there.
I can use also every other port, it will not work. It works only when I
bind to port 80, just as socket lookup would be made always with the
original port instead of the --on-port 18080 in this case.
but it is not. i see in debug output that it finds the socket on port 18080.
ip address is on the bridge interface, not on the physical interface and
squid is listening on 0.0.0.0
next thing i will do is trying with a more recent kernel,.. also if
3.2.54 should be sufficient. but who knows.
peter
