Hi
I have another suspicion: Your setup works for the first time ever.
But now you have the problem that your mangleling (or mangling?) strikes before the masquerading works.
That was it. I suspected it since yesterday. All I have had to force my configuration working was to make: echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter I even did not turn SuSEfirewall2 off. And now: 1. Marked packets goes via eth2. 2. No more logs in firewall about martian-sources. The strangest thing now is: 1. First I have checked what was in /proc/sys/net/ipv4/conf/eth2/rp_filter. Was 1 ! 2. I have set up mark rule as : iptables -I PREROUTING 1 -i eth0 -t mangle -p tcp --dport 3128 -j MARK --set-mark 1 The rest of PREROUTING was set up by SuSEfirewall2 script.... And there was a lot of rules anyway. 3. I have set up /proc/sys/net/ipv4/conf/eth2/rp_filter to 0 with echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter 4. I have checked with tcpdump -i eth2 if the connection to my proxy server is working. It was!! - Supper.. but: 5. Then I have change /proc/sys/net/ipv4/conf/eth2/rp_filter to 2 (it is mentioned in that way in Adv-routing HOWTO). 6. My connection via eth2 to proxy server still works !! Rather strange, but maybe... I have checked before that all connection that was established during rp_filter set to 0 was ended of course... 7. Then I have change /proc/sys/net/ipv4/conf/eth2/rp_filter back to 1 (as it was before I have changed it to 0). Also waited long enough that all connection to my proxy server established when rp_filter = 2 was ended... 8. My connection to proxy server still works !! This is VERY STRANGE in my opinion. At the beginning it does not worked - and now after setting rp_filter to 0 and back to 1 it is. Nothing else was done in the different way I have done it on Monday. All other /proc/sys/net/ipv4/conf/*/rp_filter was all the time set to 1. And what is interesting I can see in firewall log some other martian-sources logs with eth2. With this eth2 I am connected to local ISP (in my building) which has a lot of mess in his net. But at the end it is working. Maybe somebody from SuSE or rather Linux kernel team can answer it.. As is mentioned by Adv-routing HOWTO it is kernel thing. Best regards to all.. Marcin.
You seem to send out packets with source address 192.168.0.22 and the proxy responds to this IP, but your kernel thinks that someone attacks your network with spoofed ip-addresses and logs them as martian-sources.
Like I said, this is my suspicion and I cannot confirm that. It's my idea of how your networking problem
My problem is that I can not force SuSE 7.3 to send part of the packet with not standard gateway (so if standard is on eth1 then I want to send part of the traffic on eth2 with marked packets).
Scheme is little different - shame on me that I did not made it earlier:
/---------\ --eth1 +---------+ /-----\ | | | | |Proxy|----|INTERNET | | SuSE 7.3| eth0 --- Internal LAN \-----/ | | | | \---------/ --eth2 +---------+
I would recommend that you don't mangle your packets, but that you masquerade your packets the right way:
iptables -s 192.168.0.0/24 -d 0/0 -j MASQ
and add an host route to the proxy (z.z.z.z) via eth2 with metric 2 and change the default routes metric to 10.
route add -net 0.0.0.0 gw (IP <eth1>) metric 10 route del -net 0.0.0.0 gw (IP <eth1>) metric 0 route add -host z.z.z.z gw (IP <eth2>) metric 2
The goal is to have now the default gw pointing to the end of eth1 but with an increased metric and another route to the proxy with a cheaper metric.
Please try this. I tried it and it seemed to work. The difference in this setup and your setup is that all packets to z.z.z.z will traverse eth2.
Peter
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com