IPFW1 rule 'deny icmp from any to any icmptype 5' matches fragmented ICMP packets. How-To-Repeat: ipfw add 1 deny icmp from any to any icmptype 5 Try to ping external host with big ICMP packets: ping -s 2000 host
Hello, Could you please test a patch below? Thanks. Index: sys/netinet/ip_fw.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v retrieving revision 1.131.2.39 diff -u -r1.131.2.39 ip_fw.c --- sys/netinet/ip_fw.c 20 Jan 2003 02:23:07 -0000 1.131.2.39 +++ sys/netinet/ip_fw.c 24 Apr 2003 11:12:02 -0000 @@ -1434,7 +1434,7 @@ struct icmp *icmp; if (offset != 0) /* Type isn't valid */ - break; + continue; icmp = (struct icmp *) ((u_int32_t *)ip + ip->ip_hl); if (!icmptype_match(icmp, f)) continue; %%% -- Maxim Konovalov, maxim@macomnet.ru, maxim@FreeBSD.org
Add to audit trail. -- Maxim Konovalov, maxim@macomnet.ru, maxim@FreeBSD.org ---------- Forwarded message ---------- Date: Thu, 24 Apr 2003 14:35:58 +0300 From: Andrey Lakhno <land@dnepr.net> To: Maxim Konovalov <maxim@macomnet.ru> Subject: Re: kern/51341: ipfw rule 'deny icmp from any to any icmptype 5' matches fragmented icmp packets Hello, On Thu, 24 Apr 2003, Maxim Konovalov wrote: > Could you please test a patch below? Thanks. It works. Thank you ! > Index: sys/netinet/ip_fw.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v > retrieving revision 1.131.2.39 > diff -u -r1.131.2.39 ip_fw.c > --- sys/netinet/ip_fw.c 20 Jan 2003 02:23:07 -0000 1.131.2.39 > +++ sys/netinet/ip_fw.c 24 Apr 2003 11:12:02 -0000 > @@ -1434,7 +1434,7 @@ > struct icmp *icmp; > > if (offset != 0) /* Type isn't valid */ > - break; > + continue; > icmp = (struct icmp *) ((u_int32_t *)ip + ip->ip_hl); > if (!icmptype_match(icmp, f)) > continue; > > %%% -- Andrey Lakhno, land-ripe
Responsible Changed From-To: freebsd-bugs->ipfw Over to maintainer group.
Hello Andrey, Here is another workaround: add a following rule before any icmp deny rules: ipfw add pass icmp from any to any frag I would like to describe the problem in two words. Please consider a next rule: deny icmp from any to any icmptype 5 Consider we get an icmp fragment. In fact, it does not consist information about its type and due to the discussed bug ipfw1 will terminate the search and drop it. ipfw2 behaviour is different: if we do not know about icmp type of the packet do not terminate the search and check the packet against next rule. At the moment I really do not want to fix this bug because it changes a filtering policy and may have a negative effect to countless installations. Please let me know if you are satisfied with my explanation and I can close the PR. Thanks! -- Maxim Konovalov, maxim@macomnet.ru, maxim@FreeBSD.org
State Changed From-To: open->feedback Feedback awating.
---------- Forwarded message ---------- Date: Fri, 4 Jul 2003 13:47:56 +0300 From: Andrey Lakhno <land@dnepr.net> To: Maxim Konovalov <maxim@macomnet.ru> Subject: Re: kern/51341 Hello, On Thu, 03 Jul 2003, Maxim Konovalov wrote: > Here is another workaround: add a following rule before any icmp deny > rules: > > ipfw add pass icmp from any to any frag > > I would like to describe the problem in two words. Please consider a > next rule: > > deny icmp from any to any icmptype 5 > > Consider we get an icmp fragment. In fact, it does not consist > information about its type and due to the discussed bug ipfw1 will > terminate the search and drop it. ipfw2 behaviour is different: if we > do not know about icmp type of the packet do not terminate the search > and check the packet against next rule. > > At the moment I really do not want to fix this bug because it changes > a filtering policy and may have a negative effect to countless > installations. > > Please let me know if you are satisfied with my explanation and I can > close the PR. I think this bug should be decribed in ipfw(8) or fixed. -- Andrey Lakhno, land-ripe
Responsible Changed From-To: freebsd-ipfw->remko grab this; had this ever been fixed?
State Changed From-To: feedback->suspended Feedback was received some time ago. It sounds as though this behavior should simply be documented?
State Changed From-To: suspended->closed
State Changed From-To: closed->suspended Closed unintentionally. Restore its state.
State Changed From-To: suspended->open This is likely to be documented, but I will not do this, reassign to the pool
Responsible Changed From-To: remko->freebsd-doc Reassign to the pool; this should probably be documented, but I will not do that.
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
Fixed some time ago: "ipfw add 1 deny icmp from any to any icmptype 5" does not match fragments, as documented.