tproxy 4.1.0 on kernel 2.6.24 is not working and I haven't tested any other kernel version :- Issues ====== 1. Failed to compile. I fixed the compilation problem by taking two of the patches from 2.6.25 and apply them onto 2.6.24, namely netfilter_ip_route_me_harder patch and inet_sock_and_route_dependency.patch. 2. socket in IP_TRANSPARENT mode failed to received return packets both in bridge mode and nat mode. According to the docs, I have executed this script :- iptables -t mangle -F iptables -t mangle -N DIVERT iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY \ --tproxy-mark 0x1/0x1 -on-port 3128 iptables -t mangle -A DIVERT -j MARK --set-mark 1 iptables -t mangle -A DIVERT -j ACCEPT They were executed without any error. 3. In the bridge mode case, when I execute a simple 'ip spoofing' program ( which I posted here previously, but I changed IP_FREEBIND to IP_TRANSPARENT ), there packets appearing in the DIVERT target and the TPROXY target, but they are delivered to the machined which IP has been spoofed ( by right they are supposed to be delivered locally to the spoofing program ). 4. In the nat mode, packets leaving the interface SNAT-ed and so there are reply packets however the local socket program is not receiving either. Packets do not hit the DIVERT and TPROXY targets at all, ie the iptables counter return 0 bytes. 5. When I execute ebtables commands on the br0 interface, there will be kernel panic. Example of the commands which can cause panic :- ebtables -t broute -A BROUTING --logical-in br0 -p ipv4 --ip-protocol tcp \ --ip-destination-port 80 -j redirect --redirect-target ACCEPT Regards. -------------------------------------------- Important Warning! *************************** This electronic communication (including any attached files) may contain confidential and/or legally privileged information and is only intended for the use of the person to whom it is addressed. If you are not the intended recipient, you do not have permission to read, use, disseminate, distribute, copy or retain any part of this communication or its attachments in any form. If this e-mail was sent to you by mistake, please take the time to notify the sender so that they can identify the problem and avoid any more mistakes in sending e-mail to you. The unauthorised use of information contained in this communication or its attachments may result in legal action against any person who uses it.
Hi, Ming-Ching Tiew wrote:
tproxy 4.1.0 on kernel 2.6.24 is not working and I haven't tested any other kernel version :-
Issues ====== 1. Failed to compile.
I fixed the compilation problem by taking two of the patches from 2.6.25 and apply them onto 2.6.24, namely netfilter_ip_route_me_harder patch and inet_sock_and_route_dependency.patch.
AFAIK the older version is for 2.6.23 (in October), the newer for the net-2.6 (originally net-2.6.25), also 2.6.24 is not explicitly supported.
2. socket in IP_TRANSPARENT mode failed to received return packets both in bridge mode and nat mode.
According to the docs, I have executed this script :-
iptables -t mangle -F iptables -t mangle -N DIVERT iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY \ --tproxy-mark 0x1/0x1 -on-port 3128 iptables -t mangle -A DIVERT -j MARK --set-mark 1 iptables -t mangle -A DIVERT -j ACCEPT
They were executed without any error.
You may missed to set up routing: ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100 It is required for tproxy.
3. In the bridge mode case, when I execute a simple 'ip spoofing' program ( which I posted here previously, but I changed IP_FREEBIND to IP_TRANSPARENT ), there packets appearing in the DIVERT target and the TPROXY target, but they are delivered to the machined which IP has been spoofed ( by right they are supposed to be delivered locally to the spoofing program ).
Does this occur when you use advanced routing?
4. In the nat mode, packets leaving the interface SNAT-ed and so there are reply packets however the local socket program is not receiving either. Packets do not hit the DIVERT and TPROXY targets at all, ie the iptables counter return 0 bytes.
We know this issue, we are going to fix this as soon as we find a good solution.
5. When I execute ebtables commands on the br0 interface, there will be kernel panic.
I'm afraid not familiar with ebtables. -- Panther
Laszlo Attila Toth wrote:
AFAIK the older version is for 2.6.23 (in October), the newer for the net-2.6 (originally net-2.6.25), also 2.6.24 is not explicitly supported.
Understand.
You may missed to set up routing:
ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100
It is required for tproxy.
Noted. The new FWMARK setup requirement is a little confusing to me at this moment. I will probably ask this in a separate post.
3. In the bridge mode case, when I execute a simple 'ip spoofing' program ( which I posted here previously, but I changed IP_FREEBIND to IP_TRANSPARENT ), there packets appearing in the DIVERT target and the TPROXY target, but they are delivered to the machined which IP has been spoofed ( by right they are supposed to be delivered locally to the spoofing program ).
Does this occur when you use advanced routing?
I have identified the reason for this to fail to work. Basically it failed to work earlier because :- 1 ) I did not set up the route as mentioned above. 2 ) Again, tproxy over bridge device has the same old problem that it requires special tricks ( mentioned a few times here in this list ) to get it right. So latest information is that tproxy 4.1.0 works in bridge mode ( subject to one has a fix/workaround to the bridge problem - which is needed for tproxy 4.0.x as well ).
We know this issue, we are going to fix this as soon as we find a good solution.
Noted.
5. When I execute ebtables commands on the br0 interface, there will be kernel panic.
I'm afraid not familiar with ebtables.
I will verify if the system will panic if I don't apply the tproxy patch. The reason why 'ebtables' is brought into the picture is to fix/workaround the bridge problem mention above. I used that for tproxy 4.0.x. Regards.
From: "Ming-Ching Tiew" <mingching.tiew@redtone.com>
5. When I execute ebtables commands on the br0 interface, there will be kernel panic.
I'm afraid not familiar with ebtables.
I will verify if the system will panic if I don't apply the tproxy patch.
Arg, it is ebtables/bridge problem which has nothing to do with tproxy. I will check if there is already a fix for it. Otherwise I think I need to get this reported to the kernel team.
Hi, Ming-Ching Tiew wrote:
tproxy 4.1.0 on kernel 2.6.24 is not working and I haven't tested any other kernel version :- [...]
4. In the nat mode, packets leaving the interface SNAT-ed and so there are reply packets however the local socket program is not receiving either. Packets do not hit the DIVERT and TPROXY targets at all, ie the iptables counter return 0 bytes.
Now it works with SNAT (on the top of net-2.6.git). The kernel and iptables patches are available here: http://people.balabit.hu/panther/tproxy/ -- Panther
participants (2)
-
Laszlo Attila Toth
-
Ming-Ching Tiew