* André Sänger wrote on Thu, Aug 07, 2003 at 09:24 +0200:
Wednesday, August 06, 2003, 11:51:12 PM, you wrote:
So it seems strange why the client connects to that address - seems to be the wrong one. Are you sure that there is really no routing for the client via eth2? Did you verified with tcpdump or similar tools?
According to the routing table the client can reach the 192.168.80.0 net via its default gateway 10.68.26.1, which has an ip adress in the 192.168.80.0 net. But why should it try to connect to 192.168.80.1 in the first place?
Well, I do not understand windows naming resolve algo. There is some broadcast and whatever based name caching that often is used instead of DNS. Well, it is difficult to understand I think. Keep in mind that the Windows system isn't designed for clear concepted networks but to allow some kind of plug'n'play. Stations in a LAN can "browse" each other without any central service as DNS or WINs. An NT router does some netbios name proxying and other magic things. Often, it is difficult to trace on the system. Yesterday we had some problem, when the DHCP server sent "sub.domain.com domain.com" as DNS seachlist. Windows happily requests "server.sub.domain.com domain.com" from the DNS server, or even "server.sub.domain.com;domain.com", not noticing that ";" isn't a valid character. Don't rely on the error messages you get from nslookup or such. Use tcpdump to see what windows is trying in reality :-) Maybe it do sent such a packet to the server and it gets droppend by rp_filter.
If I read the logmessage it seems like a packet comes from the client with a source ip adress of 192.168.80.1? How´s that possible? Or do I misunderstand the log message?
trace it! There are so many things that could have been happend ;) But yes, I think you misunderstood the message. martian source 192.168.80.1 from 10.68.26.117, on dev eth2 Aug 6 (AFIAK) this means: on eth2 arrived a packet for 192.168.80.1 (sent by 10.68.26.117). Such packet should arrvie on eth0 in your case (because it is more "near" to that network). Well, on multi-homed boxes this won't work well, because "routing to itself" produces this "martian" source - an attack isn't the case here I think :-). It is correct to reach a multihomed box by any of it's IPs from any of "allowed" interfaces (it has to "virtually" route to itself, like eth2 -> eth0 routing, but this is OK and working). So rp_filter isn't working here.
Sorry, I cannot help much with SuSEfirwall2, maybe there is a better way to do that - but should solve you problem for the time you're looking for best solution :-)
How can I put that command in the SuSEfirewall2 script so that I don´t have to issue it manuelly after SuSEfirewall2 is restarted?
Patch it! I have no copy of SuSEfirewall2 around here, so I just write from memory :-) As start, try $ cd /etc/rc.d/ $ grep "rp_filter" SuSEfi* Expect something like echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter If eth0 and eth2 are internal (somewhat trusted) devices, you may wish to protect eth1 only, because if on eth1 arrives a packet for 192.168.80.1, this indicates a spoof or something (because it is from outside, and RFC1918 should not be routed by internet!). Here rp_filter may be a good idea (in some cases). So you may wish to have instead (simply make a BACKUP and the edit the file found by the grep command, search the position, comment out the original line and add): echo "0" > /proc/sys/net/ipv4/conf/all/rp_filter echo "1" > /proc/sys/net/ipv4/conf/eth1/rp_filter (untested). You can issues those commands (as root) on any shell for testing (but of course not reboot-persistent). In case it works, change the SuSEscript, document your changes as you'll have to reply them on next version/update :-) diff+patch are your friends ( $ diff -u SuSEfirewall2.dist SuSEfirewall2 > SuSEfirewall_rp_eth1_only.patch (check the patch file if it looks reasonable) if SuSEfirewall2 is replaced, re-apply your changes: $ patch < SuSEfirewall_rp_eth1_only.patch or something like this. Well, we're getting OT :-) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.