Hi...
Am Dienstag, 22. Januar 2002 11:58 schrieb Marcin Gryszczuk:
1 - problem 1-st: I have following problem that can not solve under SuSE 7.3 with SuSEfirewall2 - kernel 2.4.16, iptables 1.2.2. Problem is that I have 2 public interfaces (eth1 - default and eth2) with 2 public IP addresses and 1 internal interface (eth0) with 192.168.0.x private class. On that last interface I have small private network which is MASUQREDED on my Linux box.
What I have also realized is that I could see some (strange for me) lines in firewall log file like:
Jan 21 11:24:01 linux kernel: martian source 192.168.0.22 from z.z.z.z, on dev eth2 Jan 21 11:24:01 linux kernel: ll header: 00:00:c0:6a:65:d3:00:c0:df:b0:c2:a8:08:00
This contains the MAC address of the offending network interface card. You'll able to see that under "Hardware address" in ifconfigs output. Is this card in the proxy?
00:00:c0:6a:65:d3 is my eth2 card HAddr. Clear... Proxy card HAddr is: 00:d0:b7:9a:38:00 - so it is not visible here (in that log)
192.168.0.22 - is my comp in my private net., z.z.z.z is my proxy server IP address (what in fact I've just realized after the whole day yesterday looking at it).
This is your kernel which tells you that you have made an mistake: It says: I got an IP-Packet from eth2 which could not originate from there if I look it up in my routing table.
That sounds OK - but is that message concerning IP 192.168.0.22 (private - this one is configured on my other pc connected to eth0 !) or z.z.z.z (which is PUBLIC IP of my proxy server staying in different city! even)
Check if your network connection is functional. It seems your proxy is not only able to talk to you via eth0, but also (and falsely) talking to you via eth2.
Missunderstanding I thing. My proxy server is z.z.z.z which is PUBLIC IP - server is even in different city.. It can not send any packet fdirest to eth0 as eth0 is private net only (192.160.0.1)
Problem is that I would like to forward part of the traffic (let say all squid proxy requests to my external server) via my 2-nd public interface (eth2). At the moment all traffic goes via default gateway (eth1). I have tried the example I could find in Adv-routing HOWTO - routing all SQUID packets to be forwarded via eth2 :
iptables -A PREROUTING -i eth0 -t mangle -p tcp --dport 3128 -j MARK --set-mark 1
My rule table looks like: #ip rule ls 0: from all lookup local 32765: from all fwmark 1 lookup ic.out 32766: from all lookup main 32767: from all lookup 253
#ip route ls table ic.out default via y.y.y.97 dev eth2
- but it does not work. What is strange I have had SuSe 6.3 before and under ipchains it worked perfectly!
What I have realized is that during testing this connection packets try to goes via eth2 - I could see it on tcpdump - but only packets with S (SYN ?) flag set appears there... And nothing else.
1) What was your ipchains-line which enabled you to make your set up functional?
Oh - very similar in fact to exampled one for iptables: ipchains -A input -i eth0 --dport 3128 -p tcp -j ACCEPT -m 1 (making packets comming from eth0 and destined to any addr to 3128 (SQUID proxy server standard port) to be marked with 1)
2) Are you sure that your proxy host has the right routing table?
Of course - everything was working 3 days ago (before I have made changing to 7.3 on my box). Proxy server is just another linux box.
3) Have you tried an host-route to your proxy via eth0?
As I mentioned above I can not route to my proxy server via eth0 - this is only for private net use. I can reach proxy via eth1 and eth2 if I configure default gateway to be on eth1 or eth2 . 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 +---------+ Maybe now it will be more clear... to help me... Regards Marcin