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 > > > > > > > > > -- 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:
some.firewall.sh
Description: application/shellscript
Attachment:
signature.asc
Description: This is a digitally signed message part
