Hi Amos Thank you for the prompt reply! On 01/27/2014 10:04 PM, Amos Jeffries wrote: >> I proved with iptables logging rules that routing is correct, because >> packets are coming in the INPUT chain instead of FORWARD and are marked >> as they should be. > > Good. > Are there any rules in there that would prevent port 18080 packets > being accepted? No, I removed all rules completely: iptables -I INPUT -j ACCEPT ebtables -I INPUT -j ACCEPT did also iptables -t mangle -F before building the tproxy rules, which are: (iptables-save) *mangle [..] :DIVERT - [0:0] -A PREROUTING -p tcp -m socket -j DIVERT -A PREROUTING -p tcp -m tcp --dport 80 -j TPROXY --on-port 18080 --tproxy-mark 0x1/0x1 -A DIVERT -j MARK --set-xmark 0x1/0xffffffff -A DIVERT -j ACCEPT routing is: ip route add local 0.0.0.0/0 dev lo table 100 ip ru add fwmark 1/1 lookup 100 (i tried also with dev eth0 instead of lo) i guess this is all correct, because it works when it does not need to redirect to another port. so at least routing and the marking stuff is correctly working. >> I tried with both, squid 3.2.1 and 3.3.8 and with kernels 2.6.32 and >> 3.2.54 and combinations. Always the same result. > > Kernel 2.6.32 is older than the minimum version (*.37). The older 2.6 > have some TPROXY commits, but have bugs such as ICMP packets about > TPROXY connection issues not being handled by the kernel properly which > result in these strange packet disappearances). ok, i read that. that's why i tried also with 3.2.54, have that one currently running. > I have also been seeing some posts about regressions and memory leaks in > the netfilter mailing lists these last few months. I'm not sure if those > issues made it to the stable kernels, but would be late 3.10+ versions > if so. hmm, maybe i should ask on the netfilter list as well (?). >> Does anyone have some hints where I could look at in order to solve this? > > My first port of call would be the packet forwarding settings of the > kernel and later iptables rules. Since TPROXY does not alter the packet > IPs they have "non-local" values when passing through all the normal > kernel forwarding permit/deny checks between the "mangle" table and the > Squid process socket. ah, forgot to mention. i have eth0 and eth1 within a bridge. the system is in "stealth mode". forwarding does work, because if i remove the tproxy mangle rule, packets go through normally. Also squid is not the problem. If I use it directly also works. > I think RP filter is only affecting the outgoing traffic, but that could > be worth checking as well. i disabled all filters: cat /proc/sys/net/ipv4/conf/*/rp_filter 0 0 .. but.. the fact that redirecting to the same port does actually work tells me rp-filter is ok, since ip addresses in that case also are not altered and it works. looking to the tproxy netfilter code i cannot see anywhere that the destination port would be changed according to --on-port. how does squid then know that it needs to accept that packet? does only the assigned socket count? is the --on-port value only used for the socket lookup with nf_tproxy_get_sock_v4() in order to assign a socket to squid? i see the redirect, which means NF_ACCEPT.. i also see packets being logged in INPUT chain. hmm. ok i retry logging within nat table. but looks to me that when packets still pass within input chain, they are already delivered to the socket, isn't it? thank you for the help. i will continue digging :) peter -- :: e n d i a n :: security with passion :: peter warasin :: http://www.endian.com :: peter@xxxxxxxxxx
