thanks for your suggestion, now indeed I don't get any strange log messages any more. And even better I reviewed the firewall configuration and found some other "strange" things in it as well :-) Udo Rader BestSolution.at GmbH http://www.bestsolution.at On Wed, 2005-06-01 at 18:21 +0300, Sertys wrote: > Well , this line : > iptables -t nat -A Cid3D99741E.0 -d 192.168.100.0/24 -j RETURN > > change it to -j DROP and it wont generate any replies. -j RETURN, returns > the packet and sends and icmp message to the src! > > > On Tue, 31 May 2005 13:33:48 +0200, Udo Rader <udo.rader@xxxxxxxxxxxxxxx> > wrote: > > > Hi Sertys, > > > > thanks for your reponse. I doubt that my entire script will help much, > > but anyway, I attached it (obfuscated a bit, of course :-) > > > > Yes, we are using traffic shaping (qdisc), but not RP_filter. > > > > The netmask for .240 is find, actually .240 _is_ the router, the router > > sends echo replies to some other hosts in the DMZ for reasons > > unknown ... > > > > And no, this is no PPP network but a leased line instead. > > > > Udo Rader > > > > BestSolution.at GmbH > > http://www.bestsolution.at > > > > On Wed, 2005-06-01 at 15:57 +0300, Sertys wrote: > >> I was totally wrong and realised it a min after sending. In fact why > >> don't > >> you post your whole script. Do you use connection limiting? RP_filter? > >> First - check that the netmask is set correctly on 240. As long as they > >> are on the same segment, they aren't suppose to talk via the router. > >> They > >> just have to ARP discover each other and talk directly. A machine gets > >> to > >> default gw, when the ip is not in the routing table. IS THIS A PPP > >> network? > >> > >> > >> > >> On Wed, 01 Jun 2005 15:50:35 +0300, Sertys <sertys@xxxxxxxxxxxxxx> > >> wrote: > >> > >> > On Tue, 31 May 2005 10:42:36 +0200, Udo Rader > >> > <udo.rader@xxxxxxxxxxxxxxx> wrote: > >> > > >> > Those are illegal packets: > >> >> DROP IN= OUT=eth1 SRC=192.168.100.240 DST=192.168.100.10 LEN=28 > >> TOS=0x00 > >> >> PREC=0x00 TTL=64 ID=32153 PROTO=ICMP TYPE=0 CODE=0 ID=45639 SEQ=0 > >> > There's no type0&code0 combination. > >> > > >> > > >> >> Hi, > >> >> > >> >> I am stuck with a strange phenonemon where iptables drops packages it > >> >> (probably) shouldn't. > >> >> > >> >> The dropped packages are logged like this: > >> >> > >> >> DROP IN= OUT=eth1 SRC=192.168.100.240 DST=192.168.100.10 LEN=28 > >> TOS=0x00 > >> >> PREC=0x00 TTL=64 ID=32153 PROTO=ICMP TYPE=0 CODE=0 ID=45639 SEQ=0 > >> >> > >> >> So that means that this is about an icmp echo reply, originating from > >> >> 192.168.100.240, pending to be sent through its internal interface > >> >> (eth1) and destined to 192.168.100.10. > >> >> > >> >> It is completely mysterious to me where this reply comes from, but > >> >> that's not all. > >> >> > >> >> Each of the two hosts involved can ping each other and in the case > >> of a > >> >> ping, iptables does not drop any packages. > >> >> > >> >> If I shut down 192.168.100.10 (a box within the DMZ), it doesn't take > >> >> long until iptables starts to drop packages destined to other boxes > >> in > >> >> the DMZ. > >> >> > >> >> One of the first rules in my iptables setup is this: > >> >> > >> >> iptables -A INPUT -s 192.168.100.0/24 -m state --state NEW -j ACCEPT > >> >> iptables -A OUTPUT -s 192.168.100.0/24 -m state --state NEW -j ACCEPT > >> >> iptables -A FORWARD -s 192.168.100.0/24 -m state --state NEW -j > >> ACCEPT > >> >> > >> >> For the internal interface this is the first rule: > >> >> > >> >> iptables -A INPUT -i eth1 -s 192.168.100.0/24 -d 192.168.100.0/24 -m > >> >> state --state NEW -j ACCEPT > >> >> iptables -A FORWARD -i eth1 -s 192.168.100.0/24 -d 192.168.100.0/24 > >> -m > >> >> state --state NEW -j ACCEPT > >> >> iptables -A OUTPUT -o eth1 -s 192.168.100.0/24 -d 192.168.100.0/24 -m > >> >> state --state NEW -j ACCEPT > >> >> iptables -A FORWARD -o eth1 -s 192.168.100.0/24 -d 192.168.100.0/24 > >> -m > >> >> state --state NEW -j ACCEPT > >> >> > >> >> The rule that drops the package is the very last one (the 'catch > >> all') > >> >> rule. > >> >> > >> >> This is something new, because I haven't changed the iptaples setup > >> for > >> >> quite some time, so if anybody has any guess on what's going on here. > >> >> > >> >> Udo Rader > >> >> > >> >> BestSolution.at GmbH > >> >> http://www.bestsolution.at > >> > > >> > > >> > > >> > >> > >> > > > > -- > www.supportivo.org > > I can't stop myself checking for pigs in the outlets. Everybody thinks i'm > a punk, cause of the hairstyle(220V). > end -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ udo rader technischer leiter/CEM mobile ++43 660 5263642 ------------------------------------------------------------------------ eduard-bodem-gasse 8/3 A-6020 innsbruck fax ++43 512 935833 http://www.bestsolution.at phone ++43 512 935834
Attachment:
signature.asc
Description: This is a digitally signed message part
