Re: [Fwbuilder-discussion] ICMP rule strangeness ... it sorta works.
Brought to you by:
mikehorn
Menu
▾
▴
Re: [Fwbuilder-discussion] ICMP rule strangeness ... it sorta works.
|
From: Vadim K. <va...@vk...> - 2004-08-29 19:49:27
|
On Aug 29, 2004, at 12:25 PM, OpenMacNews wrote: > hi, > > i'm seeing the following ICMP traffic caught by a catch-all rule: > > Aug 26 15:40:58 linksys kernel: [Catch: global(13) DENY] IN= OUT=br0 > SRC=10.0.0.1 DST=10.0.0.2 LEN=88 TOS=0x00 PREC=0xC0 TTL=64 ID=59800 > PROTO=ICMP TYPE=3 CODE=1 [SRC=10.0.0.2 DST=202.12.27.33 LEN=60 > TOS=0x00 PREC=0x00 TTL=63 ID=4280 PROTO=UDP SPT=53 DPT=53 LEN=40 ] > > PROTO=ICMP TYPE=3 CODE=1 this is "host unreachable" > IN= OUT=br0 this means the packet has been generated by the firewall itself (it did not enter it since there is no ingress interface) > SRC=10.0.0.1 DST=10.0.0.2 source is 10.0.0.1, which is a firewall. This matches conclusion drawn from the "IN= OUT=br0" > [SRC=10.0.0.2 DST=202.12.27.33 LEN=60 TOS=0x00 PREC=0x00 TTL=63 > ID=4280 PROTO=UDP SPT=53 DPT=53 LEN=40 ] stuff in square brackets is an original packet the "host unreachable" was generated for. This packet was sent by machine 10.0.0.2 to 202.12.27.33 and it was a DNS query. It is hard to say why host 202.12.27.33 was unreachable, may be there is no rule to permit outbound DNS queries ? I can't say without seeing the policy. Or this could be a rule where you blocked all 202 networks. If the latter, did you use action Reject in it ? In any case, I would add a rule to permit service group "Useful ICMP" from any to internal network. This should cover the same ICMP messages generated by the firewall. > Aug 28 17:47:32 linksys kernel: [Catch: global(13) DENY] IN= OUT=br0 > SRC=10.0.0.1 DST=10.0.0.6 LEN=80 TOS=0x00 PREC=0xC0 TTL=64 ID=12708 > PROTO=ICMP TYPE=11 CODE=0 [SRC=10.0.0.6 DST=65.182.143.151 LEN=52 > TOS=0x00 PREC=0x00 TTL=1 ID=3563 DF PROTO=ICMP TYPE=8 CODE=0 ID=33434 > SEQ=23642 ] this is ICMP type=11 code=0, which is "time exceeded in transit". You ran traceroute from 10.0.0.6. Is 10.0.0.6 a Windows box ? I thought you only have Macs :-) I am not 100% sure, but I think both ICMPs are not matched by RELATED. I always had to add a stateless rule for 11/0 to make traceroute work. See below for more comments. > despite having setup (properly) a 'ESTABLISHED/RELATED' NAT rule & an > Internal LAN rule > > > for reference, the rules are: > > NAT: > > echo \"Rule 3(NAT)\" > > \$IPTABLES -t nat -A POSTROUTING -o vlan1 -s 10.0.0.0/24 -j SNAT > --to-source xx.xx.xx.xx > > \$IPTABLES -t nat -A POSTROUTING -o vlan1 -s 10.0.0.0/24 -j SNAT > --to-source yy.yy.yy.yy > > \$IPTABLES -t nat -A POSTROUTING -o br0 -s 10.0.0.0/24 -j SNAT > --to-source 10.0.0.1 what is the purpose of the last rule ? > > > > > > \$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT > > \$IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT > > \$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > > > > \$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP > > \$IPTABLES -A OUTPUT -p tcp ! --syn -m state --state NEW -j DROP > > \$IPTABLES -A FORWARD -p tcp ! --syn -m state --state NEW -j DROP > > > INTERNAL LAN: > > echo \"Rule 0(br0)\" > > \$IPTABLES -A INPUT -i br0 -s 10.0.0.0/24 -d 10.0.0.0/24 -m > state --state NEW -j ACCEPT > > \$IPTABLES -A FORWARD -i br0 -s 10.0.0.0/24 -d 10.0.0.0/24 -m > state --state NEW -j ACCEPT > > \$IPTABLES -A OUTPUT -o br0 -s 10.0.0.0/24 -d 10.0.0.0/24 -m > state --state NEW -j ACCEPT > > \$IPTABLES -A FORWARD -o br0 -s 10.0.0.0/24 -d 10.0.0.0/24 -m > state --state NEW -j ACCEPT > why do you need these ? If you have a /24 inside your network and all machines on your LAN are properly configured, there should be no need in these rules. I do know cases when rules like that are needed, but those cases are mostly caused by broken configuration. E.g. if you have a machine on 10.0.0.0/24 and add a route to network 10.0.0.0/24 via a firewall, the machine will forward all packets headed for other machines on the same subnet to the firewall instead of sending them directly. This is rarely needed and is most of the case a broken configuration. Do not do it. And if you do not have this on your network, you should not need the rules quoted above. Save yourself some bytes in nvram. > where: > 10.0.0.1 --> linksys firewall > 10.0.0.2 --> NAT'd smtp server & nameserver > 10.0.0.6 --> workstation > > > the combo of these rules SHOULD allow the ICMP traffic above, no? the > strange thing is my traceroutes, pings, lookups, etc. from inside my > network SEEM to be functioning properly ... i just see these 'catches' > in the logs. > do you see the firewall in the tracroute output or do you get '*' for where the firewall should be? Since ICMP 11/0 is blocked, I'd guess you should see stars. > the global(13), catch--all rule is: > > echo \"Rule 13(global)\" > > \$IPTABLES -N RULE_13 > > \$IPTABLES -A OUTPUT -j RULE_13 > > \$IPTABLES -A INPUT -j RULE_13 > > \$IPTABLES -A FORWARD -j RULE_13 > > \$IPTABLES -A RULE_13 -m limit --limit 50/minute -j LOG > --log-level info --log-prefix \"[Catch: global(13) DENY] \" > > \$IPTABLES -A RULE_13 -j DROP > > > > richard > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > Fwbuilder-discussion mailing list > Fwb...@li... > https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion |