mysterious dropped echo replies

mysterious dropped echo replies

[Udo Rader]

[-- Attachment #1: Type: text/plain, Size: 1854 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: mysterious dropped echo replies

[Sertys]

On Tue, 31 May 2005 10:42:36 +0200, Udo Rader <udo.rader@bestsolution.at>  
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

Re: mysterious dropped echo replies

[Sertys]

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@supportivo.org> wrote:

> On Tue, 31 May 2005 10:42:36 +0200, Udo Rader  
> <udo.rader@bestsolution.at> 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

Re: mysterious dropped echo replies

[Udo Rader]

[-- Attachment #1.1: Type: text/plain, Size: 4005 bytes --]

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@supportivo.org> wrote:
> 
> > On Tue, 31 May 2005 10:42:36 +0200, Udo Rader  
> > <udo.rader@bestsolution.at> 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
> >
> >
> >
> 
> 
> 
-- 
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 #1.2: some.firewall.sh --]
[-- Type: application/x-shellscript, Size: 20616 bytes --]

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: mysterious dropped echo replies

[Sertys]

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@bestsolution.at>  
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@supportivo.org>  
>> wrote:
>>
>> > On Tue, 31 May 2005 10:42:36 +0200, Udo Rader
>> > <udo.rader@bestsolution.at> 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

Re: mysterious dropped echo replies

[Udo Rader]

[-- Attachment #1: Type: text/plain, Size: 5213 bytes --]

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@bestsolution.at>  
> 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@supportivo.org>  
> >> wrote:
> >>
> >> > On Tue, 31 May 2005 10:42:36 +0200, Udo Rader
> >> > <udo.rader@bestsolution.at> 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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: mysterious dropped echo replies

[Clemente Aguiar]

[-- Attachment #1: Type: text/plain, Size: 6273 bytes --]


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@lists.netfilter.org
[mailto:netfilter-bounces@lists.netfilter.org] 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@bestsolution.at>
> 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@supportivo.org>
> >> wrote:
> >>
> >> > On Tue, 31 May 2005 10:42:36 +0200, Udo Rader 
> >> > <udo.rader@bestsolution.at> 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 #2: fw.sh --]
[-- Type: application/octet-stream, Size: 14176 bytes --]

#!/bin/sh 
#
IPTABLES_RESTORE="iptables-restore"
cat << EOF | $IPTABLES_RESTORE
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT   -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT  -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# 
# Rule 0 (eth0)
# 
# anti spoofing rule
# 
:eth0_In_RULE_0 - [0:0]
-A INPUT  -i eth0  -s 64.48.194.253  -j eth0_In_RULE_0 
-A INPUT  -i eth0  -s 64.48.194.190  -j eth0_In_RULE_0 
-A INPUT  -i eth0  -s 64.48.194.238  -j eth0_In_RULE_0 
-A INPUT  -i eth0  -s 64.48.194.250  -j eth0_In_RULE_0 
-A INPUT  -i eth0  -s 192.168.2.233  -j eth0_In_RULE_0 
-A INPUT  -i eth0  -s 64.48.194.128/26  -j eth0_In_RULE_0 
-A INPUT  -i eth0  -s 64.48.194.224/28  -j eth0_In_RULE_0 
-A INPUT  -i eth0  -s 64.48.194.248/30  -j eth0_In_RULE_0 
-A FORWARD  -i eth0  -s 64.48.194.253  -j eth0_In_RULE_0 
-A FORWARD  -i eth0  -s 64.48.194.190  -j eth0_In_RULE_0 
-A FORWARD  -i eth0  -s 64.48.194.238  -j eth0_In_RULE_0 
-A FORWARD  -i eth0  -s 64.48.194.250  -j eth0_In_RULE_0 
-A FORWARD  -i eth0  -s 192.168.2.233  -j eth0_In_RULE_0 
-A FORWARD  -i eth0  -s 64.48.194.128/26  -j eth0_In_RULE_0 
-A FORWARD  -i eth0  -s 64.48.194.224/28  -j eth0_In_RULE_0 
-A FORWARD  -i eth0  -s 64.48.194.248/30  -j eth0_In_RULE_0 
-A eth0_In_RULE_0    -m limit --limit 5/second -j LOG  --log-level info --log-prefix "FW-RULE 0 -- DENY "
-A eth0_In_RULE_0   -j DROP 
# 
# Rule 0 (eth4)
# 
# anti spoofing rule
# 
:eth4_In_RULE_0 - [0:0]
-A INPUT  -i eth4  -s 64.48.194.253  -j eth4_In_RULE_0 
-A INPUT  -i eth4  -s 64.48.194.190  -j eth4_In_RULE_0 
-A INPUT  -i eth4  -s 64.48.194.238  -j eth4_In_RULE_0 
-A INPUT  -i eth4  -s 64.48.194.250  -j eth4_In_RULE_0 
-A INPUT  -i eth4  -s 192.168.2.233  -j eth4_In_RULE_0 
-A INPUT  -i eth4  -s 64.48.194.252/30  -j eth4_In_RULE_0 
-A INPUT  -i eth4  -s 64.48.194.224/28  -j eth4_In_RULE_0 
-A INPUT  -i eth4  -s 64.48.194.248/30  -j eth4_In_RULE_0 
-A FORWARD  -i eth4  -s 64.48.194.253  -j eth4_In_RULE_0 
-A FORWARD  -i eth4  -s 64.48.194.190  -j eth4_In_RULE_0 
-A FORWARD  -i eth4  -s 64.48.194.238  -j eth4_In_RULE_0 
-A FORWARD  -i eth4  -s 64.48.194.250  -j eth4_In_RULE_0 
-A FORWARD  -i eth4  -s 192.168.2.233  -j eth4_In_RULE_0 
-A FORWARD  -i eth4  -s 64.48.194.252/30  -j eth4_In_RULE_0 
-A FORWARD  -i eth4  -s 64.48.194.224/28  -j eth4_In_RULE_0 
-A FORWARD  -i eth4  -s 64.48.194.248/30  -j eth4_In_RULE_0 
-A eth4_In_RULE_0    -m limit --limit 5/second -j LOG  --log-level info --log-prefix "FW-RULE 0 -- DENY "
-A eth4_In_RULE_0   -j DROP 
# 
# Rule 0 (lo)
# 
# 
# 
-A INPUT  -i lo  -m state --state NEW  -j ACCEPT 
-A OUTPUT  -o lo  -m state --state NEW  -j ACCEPT 
# 
# Rule 0 (eth2)
# 
# anti spoofing rule
# 
:eth2_In_RULE_0 - [0:0]
-A INPUT  -i eth2  -s 64.48.194.253  -j eth2_In_RULE_0 
-A INPUT  -i eth2  -s 64.48.194.190  -j eth2_In_RULE_0 
-A INPUT  -i eth2  -s 64.48.194.238  -j eth2_In_RULE_0 
-A INPUT  -i eth2  -s 64.48.194.250  -j eth2_In_RULE_0 
-A INPUT  -i eth2  -s 192.168.2.233  -j eth2_In_RULE_0 
-A INPUT  -i eth2  -s 64.48.194.248/30  -j eth2_In_RULE_0 
-A INPUT  -i eth2  -s 64.48.194.252/30  -j eth2_In_RULE_0 
-A INPUT  -i eth2  -s 64.48.194.128/26  -j eth2_In_RULE_0 
-A FORWARD  -i eth2  -s 64.48.194.253  -j eth2_In_RULE_0 
-A FORWARD  -i eth2  -s 64.48.194.190  -j eth2_In_RULE_0 
-A FORWARD  -i eth2  -s 64.48.194.238  -j eth2_In_RULE_0 
-A FORWARD  -i eth2  -s 64.48.194.250  -j eth2_In_RULE_0 
-A FORWARD  -i eth2  -s 192.168.2.233  -j eth2_In_RULE_0 
-A FORWARD  -i eth2  -s 64.48.194.248/30  -j eth2_In_RULE_0 
-A FORWARD  -i eth2  -s 64.48.194.252/30  -j eth2_In_RULE_0 
-A FORWARD  -i eth2  -s 64.48.194.128/26  -j eth2_In_RULE_0 
-A eth2_In_RULE_0    -m limit --limit 5/second -j LOG  --log-level info --log-prefix "FW-RULE 0 -- DENY "
-A eth2_In_RULE_0   -j DROP 
# 
# Rule 0 (eth5)
# 
# anti spoofing rule
# 
:eth5_In_RULE_0 - [0:0]
-A INPUT  -i eth5  -s 64.48.194.253  -j eth5_In_RULE_0 
-A INPUT  -i eth5  -s 64.48.194.190  -j eth5_In_RULE_0 
-A INPUT  -i eth5  -s 64.48.194.238  -j eth5_In_RULE_0 
-A INPUT  -i eth5  -s 64.48.194.250  -j eth5_In_RULE_0 
-A INPUT  -i eth5  -s 192.168.2.233  -j eth5_In_RULE_0 
-A INPUT  -i eth5  -s 64.48.194.128/26  -j eth5_In_RULE_0 
-A INPUT  -i eth5  -s 64.48.194.224/28  -j eth5_In_RULE_0 
-A INPUT  -i eth5  -s 64.48.194.252/30  -j eth5_In_RULE_0 
-A FORWARD  -i eth5  -s 64.48.194.253  -j eth5_In_RULE_0 
-A FORWARD  -i eth5  -s 64.48.194.190  -j eth5_In_RULE_0 
-A FORWARD  -i eth5  -s 64.48.194.238  -j eth5_In_RULE_0 
-A FORWARD  -i eth5  -s 64.48.194.250  -j eth5_In_RULE_0 
-A FORWARD  -i eth5  -s 192.168.2.233  -j eth5_In_RULE_0 
-A FORWARD  -i eth5  -s 64.48.194.128/26  -j eth5_In_RULE_0 
-A FORWARD  -i eth5  -s 64.48.194.224/28  -j eth5_In_RULE_0 
-A FORWARD  -i eth5  -s 64.48.194.252/30  -j eth5_In_RULE_0 
-A eth5_In_RULE_0    -m limit --limit 5/second -j LOG  --log-level info --log-prefix "FW-RULE 0 -- DENY "
-A eth5_In_RULE_0   -j DROP 
# 
# Rule 0 (global)
# 
# Blocking unwanted types of packets.
# - IP Fragments
# - SCAN XMAS (see SNORT)
# - SCAN nmap XMAS (see SNORT)
# - SCAN nmap fingerprint attempt
# 
:RULE_0 - [0:0]
-A OUTPUT -p all  -f   -j RULE_0 
-A OUTPUT -p tcp -m tcp  --tcp-flags ALL URG,PSH,FIN  -j RULE_0 
-A OUTPUT -p tcp -m tcp  --tcp-flags ALL URG,ACK,PSH,RST,SYN,FIN  -j RULE_0 
-A OUTPUT -p tcp -m tcp  --tcp-flags ALL URG,PSH,SYN,FIN  -j RULE_0 
-A INPUT -p all  -f   -j RULE_0 
-A INPUT -p tcp -m tcp  --tcp-flags ALL URG,PSH,FIN  -j RULE_0 
-A INPUT -p tcp -m tcp  --tcp-flags ALL URG,ACK,PSH,RST,SYN,FIN  -j RULE_0 
-A INPUT -p tcp -m tcp  --tcp-flags ALL URG,PSH,SYN,FIN  -j RULE_0 
-A FORWARD -p all  -f   -j RULE_0 
-A FORWARD -p tcp -m tcp  --tcp-flags ALL URG,PSH,FIN  -j RULE_0 
-A FORWARD -p tcp -m tcp  --tcp-flags ALL URG,ACK,PSH,RST,SYN,FIN  -j RULE_0 
-A FORWARD -p tcp -m tcp  --tcp-flags ALL URG,PSH,SYN,FIN  -j RULE_0 
-A RULE_0   -m limit --limit 5/second -j LOG  --log-level info --log-prefix "FW-RULE 0 -- DENY "
-A RULE_0  -j DROP 
# 
# Rule 1 (global)
# 
# Acesso da rede de Servers (que tb tem redes Internas) e da rede das Empresas
# 
:Cid4267E6B5.0 - [0:0]
-A FORWARD  -s 64.48.194.128/26  -m state --state NEW  -j Cid4267E6B5.0 
-A FORWARD  -s 64.48.194.224/28  -m state --state NEW  -j Cid4267E6B5.0 
-A Cid4267E6B5.0 -p tcp -m tcp  --dport 6700:6702  -j ACCEPT 
-A Cid4267E6B5.0 -p tcp -m tcp  -m multiport  --dports 443,143,22,80,53,21,25,110,113,8080,1709,5190,1755,1863,4661  -j ACCEPT 
-A Cid4267E6B5.0 -p tcp -m tcp  -m multiport  --dports 8888,6100,7000,1723,3389,211,43,5878,8003,6667,5900,5901,37,119  -j ACCEPT 
-A Cid4267E6B5.0 -p udp -m udp  -m multiport  --dports 53,1709,123,161,162,37  -j ACCEPT 
-A Cid4267E6B5.0 -p 47  -j ACCEPT 
# 
# Rule 2 (global)
# 
# 
# 
:Cid4267FD87.0 - [0:0]
-A FORWARD  -d 64.48.194.128/26  -m state --state NEW  -j Cid4267FD87.0 
-A FORWARD  -d 64.48.194.224/28  -m state --state NEW  -j Cid4267FD87.0 
-A Cid4267FD87.0 -p tcp -m tcp  --dport 6700:6702  -j ACCEPT 
-A Cid4267FD87.0 -p tcp -m tcp  -m multiport  --dports 443,143,22,80,53,21,25,110,113,8080,1709,5190,1755,1863,4661  -j ACCEPT 
-A Cid4267FD87.0 -p tcp -m tcp  -m multiport  --dports 8888,6100,7000,3389,1723,211,5878,9800  -j ACCEPT 
-A Cid4267FD87.0 -p udp -m udp  -m multiport  --dports 53,1709,123  -j ACCEPT 
-A Cid4267FD87.0 -p 47  -j ACCEPT 
# 
# Rule 3 (global)
# 
# 
# 
:Cid4268C2FE.0 - [0:0]
-A FORWARD  -s 64.48.194.232/31  -m state --state NEW  -j Cid4268C2FE.0 
-A FORWARD  -s 64.48.194.230  -m state --state NEW  -j Cid4268C2FE.0 
-A FORWARD  -s 64.48.194.231  -m state --state NEW  -j Cid4268C2FE.0 
-A FORWARD  -s 64.48.194.234  -m state --state NEW  -j Cid4268C2FE.0 
-A Cid4268C2FE.0 -p tcp -m tcp  -m multiport  --dports 500,981,18190,264  -j ACCEPT 
-A Cid4268C2FE.0 -p udp -m udp  -m multiport  --dports 500,981,2746  -j ACCEPT 
# 
# Rule 4 (global)
# 
# 
# 
:Cid4268C2DE.0 - [0:0]
-A FORWARD  -d 64.48.194.232/31  -m state --state NEW  -j Cid4268C2DE.0 
-A FORWARD  -d 64.48.194.230  -m state --state NEW  -j Cid4268C2DE.0 
-A FORWARD  -d 64.48.194.231  -m state --state NEW  -j Cid4268C2DE.0 
-A FORWARD  -d 64.48.194.234  -m state --state NEW  -j Cid4268C2DE.0 
-A Cid4268C2DE.0 -p tcp -m tcp  -m multiport  --dports 500,981,18190,264  -j ACCEPT 
-A Cid4268C2DE.0 -p udp -m udp  -m multiport  --dports 500,981,2746  -j ACCEPT 
# 
# Rule 5 (global)
# 
# 
# 
-A FORWARD -p tcp -m tcp  -s 64.48.194.154  --dport 1025:1035  -m state --state NEW  -j ACCEPT 
# 
# Rule 6 (global)
# 
# 
# 
-A FORWARD -p tcp -m tcp  -d 64.48.194.154  --dport 1025:1035  -m state --state NEW  -j ACCEPT 
# 
# Rule 7 (global)
# 
# 
# 
-A FORWARD  -s 64.48.194.170  -m state --state NEW  -j ACCEPT 
-A FORWARD  -s 213.190.196.77  -m state --state NEW  -j ACCEPT 
-A FORWARD  -s 64.48.194.148  -m state --state NEW  -j ACCEPT 
-A FORWARD  -s 64.48.194.145  -m state --state NEW  -j ACCEPT 
-A FORWARD  -s 64.48.194.147  -m state --state NEW  -j ACCEPT 
-A FORWARD  -s 64.48.194.146  -m state --state NEW  -j ACCEPT 
-A FORWARD  -s 64.48.194.149  -m state --state NEW  -j ACCEPT 
# 
# Rule 8 (global)
# 
# Atenção: Sem protecção!!!
# Verificar todos os serviços que correm nestas maquinas.
# 
-A FORWARD  -d 64.48.194.170  -m state --state NEW  -j ACCEPT 
-A FORWARD  -d 64.48.194.148  -m state --state NEW  -j ACCEPT 
-A FORWARD  -d 64.48.194.145  -m state --state NEW  -j ACCEPT 
-A FORWARD  -d 64.48.194.147  -m state --state NEW  -j ACCEPT 
-A FORWARD  -d 64.48.194.146  -m state --state NEW  -j ACCEPT 
-A FORWARD  -d 64.48.194.149  -m state --state NEW  -j ACCEPT 
-A FORWARD  -d 64.48.194.230  -m state --state NEW  -j ACCEPT 
# 
# Rule 9 (global)
# 
# 
# 
-A FORWARD -p tcp -m tcp  -d 64.48.194.173  --dport 3306  -m state --state NEW  -j ACCEPT 
# 
# Rule 10 (global)
# 
# 
# 
:Cid4268C560.0 - [0:0]
-A FORWARD  -d 64.48.194.180  -m state --state NEW  -j Cid4268C560.0 
-A Cid4268C560.0 -p tcp -m tcp  -m multiport  --dports 80,443,8003,5900,5901  -j ACCEPT 
# 
# Rule 11 (global)
# 
# 
# 
-A FORWARD -p tcp -m tcp  -d 0.0.0.0  --dport 81  -m state --state NEW  -j ACCEPT 
# 
# Rule 12 (global)
# 
# Permitir acesso da VLAN3 à Internet
# 
:Cid42613510.0 - [0:0]
-A FORWARD  -s 64.48.194.151  -m state --state NEW  -j Cid42613510.0 
-A Cid42613510.0 -p tcp -m tcp  -m multiport  --dports 445,139,135  -j RETURN 
-A Cid42613510.0 -p udp -m udp  -m multiport  --dports 138,137  -j RETURN 
-A Cid42613510.0  -m state --state NEW  -j ACCEPT 
# 
# Rule 13 (global)
# 
# SSH Access to firewall is permitted
# only from the Management network (VLAN2).
# Temporariamente permitir acesso de qualquer endereço.
# 
:Cid426134BF.0 - [0:0]
-A INPUT -p tcp -m tcp  --dport 22  -m state --state NEW  -j Cid426134BF.0 
:Cid426134BF.1 - [0:0]
-A Cid426134BF.0  -s 64.48.194.128/26  -j Cid426134BF.1 
-A Cid426134BF.0  -s 192.168.2.0/24  -j Cid426134BF.1 
-A Cid426134BF.1  -d 64.48.194.253  -j ACCEPT 
-A Cid426134BF.1  -d 64.48.194.190  -j ACCEPT 
-A Cid426134BF.1  -d 64.48.194.238  -j ACCEPT 
-A Cid426134BF.1  -d 64.48.194.250  -j ACCEPT 
-A Cid426134BF.1  -d 192.168.2.233  -j ACCEPT 
# 
# Rule 14 (global)
# 
# Permitir acesso da FW à Internet.
# Acesso necessário é:
# DNS e NTP ao dns1.madeiratecnopolo.pt
# RSYNC e HTTP para update do sistema.
# SMTP para poder enviar emails de alerta.
# 
:Cid426134C9.0 - [0:0]
-A OUTPUT  -s 64.48.194.253  -m state --state NEW  -j Cid426134C9.0 
-A OUTPUT  -s 64.48.194.190  -m state --state NEW  -j Cid426134C9.0 
-A OUTPUT  -s 64.48.194.238  -m state --state NEW  -j Cid426134C9.0 
-A OUTPUT  -s 64.48.194.250  -m state --state NEW  -j Cid426134C9.0 
-A OUTPUT  -s 192.168.2.233  -m state --state NEW  -j Cid426134C9.0 
-A Cid426134C9.0 -p icmp  -m icmp  --icmp-type 8/0   -j ACCEPT 
-A Cid426134C9.0 -p tcp -m tcp  -m multiport  --dports 80,53,873,25  -j ACCEPT 
-A Cid426134C9.0 -p udp -m udp  -m multiport  --dports 123,53  -j ACCEPT 
# 
# Rule 15 (global)
# 
# Usefull communication protocols.
# - ping request should be removed or at least limited
# - Source quench maybe?? has to be stateless
# 
-A OUTPUT -p icmp  -m icmp  --icmp-type 8/0   -m state --state NEW   -m limit --limit 1/second --limit-burst 5 -j ACCEPT 
-A OUTPUT -p icmp  -m icmp  --icmp-type 4  -m state --state NEW   -m limit --limit 1/second --limit-burst 5 -j ACCEPT 
-A OUTPUT -p udp -m udp  --dport 33434:33524  -m state --state NEW   -m limit --limit 1/second --limit-burst 5 -j ACCEPT 
-A INPUT -p icmp  -m icmp  --icmp-type 8/0   -m state --state NEW   -m limit --limit 1/second --limit-burst 5 -j ACCEPT 
-A INPUT -p icmp  -m icmp  --icmp-type 4  -m state --state NEW   -m limit --limit 1/second --limit-burst 5 -j ACCEPT 
-A INPUT -p udp -m udp  --dport 33434:33524  -m state --state NEW   -m limit --limit 1/second --limit-burst 5 -j ACCEPT 
-A FORWARD -p icmp  -m icmp  --icmp-type 8/0   -m state --state NEW   -m limit --limit 1/second --limit-burst 5 -j ACCEPT 
-A FORWARD -p icmp  -m icmp  --icmp-type 4  -m state --state NEW   -m limit --limit 1/second --limit-burst 5 -j ACCEPT 
-A FORWARD -p udp -m udp  --dport 33434:33524  -m state --state NEW   -m limit --limit 1/second --limit-burst 5 -j ACCEPT 
# 
# Rule 17 (global)
# 
# Quickly reject attempts to connect
# to ident server to avoid SMTP delays
# 
-A FORWARD -p tcp -m tcp  --dport 113  -j REJECT  --reject-with tcp-reset 
# 
# Rule 18 (global)
# 
# Drop all broadcast - but NO log
# 
-A OUTPUT  -m pkttype --pkt-type broadcast  -j DROP 
-A INPUT  -m pkttype --pkt-type broadcast  -j DROP 
-A FORWARD  -m pkttype --pkt-type broadcast  -j DROP 
# 
# Rule 19 (global)
# 
# 
# 
:RULE_19 - [0:0]
-A OUTPUT  -j RULE_19 
-A INPUT  -j RULE_19 
-A FORWARD  -j RULE_19 
-A RULE_19   -m limit --limit 5/second -j LOG  --log-level info --log-prefix "FW-RULE 19 -- DENY "
-A RULE_19  -j DROP 
#
COMMIT
#
EOF
#
#
echo 1 > /proc/sys/net/ipv4/ip_forward

Re: mysterious dropped echo replies

[Jason Opperisano]

On Wed, Jun 01, 2005 at 06:21:44PM +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!

RETURN returns the packet to the calling chain, or enforces the
root chain's POLICY if there is no calling chain to return to.
your description matches what REJECT does, not RETURN.

-j

--
"Stewie: Damn the toilet. It's made slaves of you all. It just
 sits there consuming other people's feces while contributing nothing
 of its own to society."
        --Family Guy

Re: mysterious dropped echo replies

[Udo Rader]

[-- Attachment #1: Type: text/plain, Size: 1717 bytes --]

Hmm, the packages were obviously RETURNed by the line mentioned to the
global root "catch all" rule and thats exactly what should normally
happen.

In the end I neither want the packages to be dropped nor rejected but
returned instead for the inspection by other chains, but I will only
switch back to RETURN after if I've found the origin for the echo
replies.

So for now, I am quite happy with both DROP and REJECT, thanks :-)

Udo Rader

BestSolution.at GmbH
http://www.bestsolution.at

On Tue, 2005-05-31 at 22:22 -0400, Jason Opperisano wrote:
> On Wed, Jun 01, 2005 at 06:21:44PM +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!
> 
> RETURN returns the packet to the calling chain, or enforces the
> root chain's POLICY if there is no calling chain to return to.
> your description matches what REJECT does, not RETURN.
> 
> -j
> 
> --
> "Stewie: Damn the toilet. It's made slaves of you all. It just
>  sits there consuming other people's feces while contributing nothing
>  of its own to society."
>         --Family Guy
-- 
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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: mysterious dropped echo replies

[Sertys]

My bad.....

On Tue, 31 May 2005 22:22:33 -0400, Jason Opperisano <opie@817west.com>  
wrote:

> On Wed, Jun 01, 2005 at 06:21:44PM +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!
>
> RETURN returns the packet to the calling chain, or enforces the
> root chain's POLICY if there is no calling chain to return to.
> your description matches what REJECT does, not RETURN.
>
> -j
>
> --
> "Stewie: Damn the toilet. It's made slaves of you all. It just
>  sits there consuming other people's feces while contributing nothing
>  of its own to society."
>         --Family Guy



-- 
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