I have a similar situation where I get mysterious dropped echo replies. May 31 18:26:37 fw1 FW-RULE 19 -- DENY IN= OUT=eth0 SRC=64.48.194.253 DST=62.183.11.71 LEN=28 TOS=0x00 PREC=0xE0 TTL=64 ID=63250 PROTO=ICMP TYPE=0 CODE=0 ID=512 SEQ=46741 May 31 19:03:36 fw1 FW-RULE 19 -- DENY IN= OUT=eth0 SRC=64.48.194.253 DST=62.118.140.48 LEN=28 TOS=0x00 PREC=0xE0 TTL=64 ID=41443 PROTO=ICMP TYPE=0 CODE=0 ID=512 SEQ=22592 Again these packets originate at the FW (64.48.194.253) running iptables, and in my case all dropped packets are destined to the outside addresses. I looked at the rules and I cannot see the reason of this behaviour. Can anybody help? Note: I attached the iptables script. Clemente -----Mensagem original----- De: netfilter-bounces@xxxxxxxxxxxxxxxxxxx [mailto:netfilter-bounces@xxxxxxxxxxxxxxxxxxx] Em nome de Udo Rader Enviada: terça-feira, 31 de Maio de 2005 17:59 Para: Netfilter list Assunto: Re: mysterious dropped echo replies 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:
fw.sh
Description: Binary data
