* mysterious dropped echo replies @ 2005-05-31 8:42 Udo Rader 2005-05-31 9:09 ` Sertys 0 siblings, 1 reply; 10+ messages in thread From: Udo Rader @ 2005-05-31 8:42 UTC (permalink / raw) To: netfilter [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mysterious dropped echo replies 2005-05-31 8:42 mysterious dropped echo replies Udo Rader @ 2005-05-31 9:09 ` Sertys 2005-05-31 9:16 ` Sertys 0 siblings, 1 reply; 10+ messages in thread From: Sertys @ 2005-05-31 9:09 UTC (permalink / raw) To: Netfilter list 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mysterious dropped echo replies 2005-05-31 9:09 ` Sertys @ 2005-05-31 9:16 ` Sertys 2005-05-31 11:33 ` Udo Rader 0 siblings, 1 reply; 10+ messages in thread From: Sertys @ 2005-05-31 9:16 UTC (permalink / raw) To: Netfilter list 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mysterious dropped echo replies 2005-05-31 9:16 ` Sertys @ 2005-05-31 11:33 ` Udo Rader 2005-05-31 11:40 ` Sertys 0 siblings, 1 reply; 10+ messages in thread From: Udo Rader @ 2005-05-31 11:33 UTC (permalink / raw) To: Netfilter list [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mysterious dropped echo replies 2005-05-31 11:33 ` Udo Rader @ 2005-05-31 11:40 ` Sertys 2005-05-31 16:58 ` Udo Rader 2005-06-01 2:22 ` Jason Opperisano 0 siblings, 2 replies; 10+ messages in thread From: Sertys @ 2005-05-31 11:40 UTC (permalink / raw) To: Netfilter list 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mysterious dropped echo replies 2005-05-31 11:40 ` Sertys @ 2005-05-31 16:58 ` Udo Rader 2005-05-31 18:38 ` Clemente Aguiar 2005-06-01 2:22 ` Jason Opperisano 1 sibling, 1 reply; 10+ messages in thread From: Udo Rader @ 2005-05-31 16:58 UTC (permalink / raw) To: Netfilter list [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: mysterious dropped echo replies 2005-05-31 16:58 ` Udo Rader @ 2005-05-31 18:38 ` Clemente Aguiar 0 siblings, 0 replies; 10+ messages in thread From: Clemente Aguiar @ 2005-05-31 18:38 UTC (permalink / raw) To: Netfilter list [-- 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mysterious dropped echo replies 2005-05-31 11:40 ` Sertys 2005-05-31 16:58 ` Udo Rader @ 2005-06-01 2:22 ` Jason Opperisano 2005-06-01 7:50 ` Udo Rader 2005-06-01 8:43 ` Sertys 1 sibling, 2 replies; 10+ messages in thread From: Jason Opperisano @ 2005-06-01 2:22 UTC (permalink / raw) To: netfilter 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mysterious dropped echo replies 2005-06-01 2:22 ` Jason Opperisano @ 2005-06-01 7:50 ` Udo Rader 2005-06-01 8:43 ` Sertys 1 sibling, 0 replies; 10+ messages in thread From: Udo Rader @ 2005-06-01 7:50 UTC (permalink / raw) To: netfilter [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mysterious dropped echo replies 2005-06-01 2:22 ` Jason Opperisano 2005-06-01 7:50 ` Udo Rader @ 2005-06-01 8:43 ` Sertys 1 sibling, 0 replies; 10+ messages in thread From: Sertys @ 2005-06-01 8:43 UTC (permalink / raw) To: Netfilter list 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2005-06-01 8:43 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-05-31 8:42 mysterious dropped echo replies Udo Rader 2005-05-31 9:09 ` Sertys 2005-05-31 9:16 ` Sertys 2005-05-31 11:33 ` Udo Rader 2005-05-31 11:40 ` Sertys 2005-05-31 16:58 ` Udo Rader 2005-05-31 18:38 ` Clemente Aguiar 2005-06-01 2:22 ` Jason Opperisano 2005-06-01 7:50 ` Udo Rader 2005-06-01 8:43 ` Sertys
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.