On Thursday 20 February 2003 05:48 pm, Dodson, Matthew wrote: > Sorry if this question has been asked before but I am having a hard > time following this iptables log. I would appreciate any help. I am > getting about 2000 of these in my logs a day. The only thing that > changes in the request are the external IP's > > > Here is my setup. > > RedHat 7.1 > iptables-1.2.5-3 > kernel-2.4.10 (I also run 2.4.20) > DROP all ICMP Generally NOT what you want to do. If you have a rule that ACCEPTs anything ESTABLISHED or RELATED, you're OK, but it appears you don't, otherwise the stuff getting dropped below would have been sent back to the server that originated the packets that the problems occured with. > server Internal IP 10.4.1.30 > > Is used as an apache webserver that gets load balanced through a css. > This server is also behind a PIX firewall. > > > IPTABLES-ICMP-IN:IN=eth1 OUT= > MAC=00:20:94:12:14:0f:00:d0:b7:82:24:9c:08:00 SRC=200.35.93.2 > DST=10.4.1.30 LEN=56 TOS=0x00 PREC=0x00 TTL=238 ID=56298 PROTO=ICMP > TYPE=3 CODE=13 [SRC=10.4.1.30 DST=200.75.116.55 LEN=48 TOS=0x00 > PREC=0x00 TTL=45 ID=0 DF PROTO=TCP INCOMPLETE [8 bytes] ] This is type3 (Destination Unreachable) code13 (Administratively Prohibited) generated in response to a connection attempt from 10.4.1.30 to 200.75.116.55. (somewhere in Venezuela, if I read correctly) The message comes from 200.35.93.2, which appears to be the gateway for the destination in question, and likely this was REJECTed by a firewall there. Probably not much you can do about this, except double-check that this traffic is actually being solicited by the firewalled destination. > IPTABLES-ICMP-IN:IN=eth1 OUT= > MAC=00:20:94:12:14:0f:00:d0:b7:82:24:9c:08:00 SRC=199.70.10.33 > DST=10.4.1.30 LEN=56 TOS=0x00 PREC=0x00 TTL=244 ID=41725 PROTO=ICMP > TYPE=11 CODE=0 [SRC=10.4.1.30 DST=12.88.181.78 LEN=40 TOS=0x00 > PREC=0x00 TTL=1 ID=34208 DF PROTO=TCP INCOMPLETE [8 bytes] ] This one is type 11 (time exceeded) code0 (TimeToLive exceeded) which tells you that TTL (decremented at each hop on the route) reached 1(as noted in the last line) before reaching the destination, and so was dropped. If you have a lot of type11code0 messages, you should check what the TTLs are for traffic leaving your network. Keep in mind that TTL will generally be decremented by each router in your internal network, so if you have several hops between the server and the iptables box (which also decrements TTL as the traffic passes through) then you are starting out onto the internet at a severe disadvantage. Generally the linux kernel will set a default TTL of 64 at origination, which is considered a reasonable limit for most traffic. If you are far below that you need to address that. (I suspect you are - the ICMP message itself has a TTL of 244, so it appears to have come a maximum of 11 hops from the point at which your outbound packet died!!) Try this: iptables -t mangle -A POSTROUTING -o eth1 -j TTL --ttl-set 64 which will reset the TTL of all outbound traffic from the iptables box to 64 and eliminate 'losses' from internal routing. If you don't have mangle table loaded, you'll also need "insmod iptable_mangle". This is precisely the sort of thing the mangle table exists for - changing TTL, TOS, or MARKing packets. (last two useful for custom routing) The theoretical limit for TTL is 255, but using anything over around 100 is considered rude at best. (except for ICMP type11 code0... :^) If your TTL is already at a 'reasonable' level and you still get TTLexceeded problems, try increasing it slightly, maybe to 70. j
