From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 21 11:06:59 2011 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A8341065672 for ; Mon, 21 Mar 2011 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7AD948FC08 for ; Mon, 21 Mar 2011 11:06:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p2LB6xK6086010 for ; Mon, 21 Mar 2011 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2LB6wGK086008 for freebsd-ipfw@FreeBSD.org; Mon, 21 Mar 2011 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Mar 2011 11:06:58 GMT Message-Id: <201103211106.p2LB6wGK086008@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 11:06:59 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/153415 ipfw [ipfw] [patch] Port numbers always zero in dynamic IPF o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw IPFIREWALL does not allow specify rules with ICMP code o kern/152887 ipfw [ipfw] Can not set more then 1024 buckets with buckets o kern/152113 ipfw [ipfw] page fault on 8.1-RELEASE caused by certain amo o kern/150798 ipfw [ipfw] ipfw2 fwd rule matches packets but does not do o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148689 ipfw [ipfw] antispoof wrongly triggers on link local IPv6 a o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148157 ipfw [ipfw] IPFW in kernel nat BUG found in FreeBSD 8.1-PRE o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. o kern/147720 ipfw [ipfw] ipfw dynamic rules and fwd o kern/145305 ipfw [ipfw] ipfw problems, panics, data corruption, ipv6 so o kern/144269 ipfw [ipfw] problem with ipfw tables o kern/144187 ipfw [ipfw] deadlock using multiple ipfw nat and multiple l o kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143653 ipfw [ipfw] [patch] ipfw nat redirect_port "buf is too smal o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/143474 ipfw [ipfw] ipfw table contains the same address f kern/142951 ipfw [dummynet] using pipes&queues gives OUCH! pipe should o kern/139581 ipfw [ipfw] "ipfw pipe" not limiting bandwidth o kern/139226 ipfw [ipfw] install_state: entry already present, done o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file. o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip o kern/122109 ipfw [ipfw] ipfw nat traceroute problem s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet] 6.3-RELEASE-p1 page fault in dummynet (corr o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 77 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 23 13:37:49 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF5861065670 for ; Wed, 23 Mar 2011 13:37:49 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 8CA9B8FC08 for ; Wed, 23 Mar 2011 13:37:49 +0000 (UTC) Received: by qyk35 with SMTP id 35so4500300qyk.13 for ; Wed, 23 Mar 2011 06:37:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=U2iL2P1d1iHwAVk4vDd5DieceX1evW8dUTjtTCArcRE=; b=w2sNy7R1nLjGyZPOOABxs3PP64StQ16vccHTv9EkJkSfUkKq4EIjkZLFB1WJe13tpc AEfjTUVg4UP2Z7sNaRHCuH+MUjrSHQrcF04N6T0m8JhL3si4t2a+ypjUpS+g3ZJxz6RC utMU9DE/jiARxPY9Pf82SXV8cYZg5+o1jIsW0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=QbQ/usQaB+ndlACh0UYA5Yf0IvrOfFjGE3lo6f2l4fB0zZ7TNeA2ZCX1qQ9nvdvm5s apcC2MFWTgMFUD60J9cwVNHXtbq71HqPE2rKq13nHVmfSx5bfPis0wlKfp7Xa6mvKg8d b39bGVfI4PfWs1MGzWgNouN8yA2IkOei9tEDA= MIME-Version: 1.0 Received: by 10.229.66.25 with SMTP id l25mr5700157qci.265.1300885411826; Wed, 23 Mar 2011 06:03:31 -0700 (PDT) Received: by 10.229.226.205 with HTTP; Wed, 23 Mar 2011 06:03:31 -0700 (PDT) Date: Wed, 23 Mar 2011 15:03:31 +0200 Message-ID: From: =?ISO-8859-1?Q?=D6zkan_KIRIK?= To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: About IPFW in-kernel NAT nat loopback X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 13:37:49 -0000 Hi, I wanna share my experiences about ipfw in-kernel nat problems with you. When a packet injects into ipfw in-kernel nat more then once, operating systems behave abnormally. Let's inspect the ruleset below: ipfw table 12 add 10.0.14.1/32 33 ipfw table 13 add X.Y.128.30/32 33 ipfw nat 33 config redirect_addr 10.0.14.1 X.Y.128.30 ipfw nat 799 config ip 3.3.3.3 reverse 55000 nat tablearg ip from table(12) to not 3.3.3.3 via em3 55000 nat tablearg ip from any to table(13) via em3 55000 nat 799 ip from any to table(13) not via em3 55000 nat tablearg ip from 3.3.3.3 to table(13) 55000 nat tablearg ip from table(12) to 3.3.3.3 55000 nat 799 ip from table(13) to 3.3.3.3 This ruleset, makes static nat. To access from a client ( i.e. 10.0.14.5 ) to X.Y.128.30, i decided to make source address translation to incoming requests. All incoming static nat requests is to be exposed to reverse nat. ( source address translation as 3.3.3.3 ) All of this ruleset works, but under 5-6 mbps static nat traffic load ( and total throughput about 150-200 Mbps ), operating system's default gateway changes unexpectedly. New default gateway shown as the local ip address of static nat ( 10.0.14.1 ). If you apply bandwidthd limiting with dummynet, this problem occurs more frequently. Dummynet catalyze the problem. when i remove the reverse nat rules as : 55000 nat tablearg ip from table(12) to any 55000 nat tablearg ip from any to table(13) everything is fine. ( default gateway doesnt change. ). Altough dummynet is active, problem doesnt seen. I think there is no problem with dummynet. I tried different rulesets for different aims, and then i understood that if you inject packets into in-kernel nat more then once system behaves unexpectedly. Another example attached below: em0: flags=8843 metric 0 mtu 1500 options=219b ether 00:23:8b:89:e4:9c inet6 fe80::223:8bff:fe89:e49c%em0 prefixlen 64 scopeid 0x1 inet X.Y.128.1 netmask 0xffffff00 broadcast X.Y.128.255 inet X.Y.128.4 netmask 0xffffffff broadcast X.Y.128.4 nd6 options=3 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8843 metric 0 mtu 1500 options=219b ether 00:23:8b:89:e4:9d inet6 fe80::223:8bff:fe89:e49d%em1 prefixlen 64 scopeid 0x2 inet 192.168.254.254 netmask 0xffffff00 broadcast 192.168.254.255 nd6 options=3 media: Ethernet autoselect (1000baseT ) status: active em2: flags=8843 metric 0 mtu 1500 options=219b ether 00:23:8b:89:e4:9e inet6 fe80::223:8bff:fe89:e49e%em2 prefixlen 64 scopeid 0x4 inet 10.200.202.254 netmask 0xffffff00 broadcast 10.200.202.255 inet 1.1.184.254 netmask 0xffffff00 broadcast 1.1.184.255 nd6 options=3 media: Ethernet autoselect (1000baseT ) status: active bce0.14: flags=8843 metric 0 mtu 1500 options=103 ether 00:1b:78:38:55:f8 inet6 fe80::223:8bff:fe89:e49c%bce0.14 prefixlen 64 scopeid 0xb inet 10.0.14.254 netmask 0xffffff00 broadcast 10.0.14.255 inet 1.1.3.254 netmask 0xffffff00 broadcast 1.1.3.255 nd6 options=3 media: Ethernet autoselect (1000baseSX ) status: active vlan: 14 parent interface: bce0 ipfw nat 800 config same_ports reset redirect_addr 192.168.254.4 X.Y.128.4 45000 nat 800 ip from 192.168.254.4 to any not via em2 // DMZ: Web_Server 45000 nat 800 ip from any to X.Y.128.4 not via em2 // DMZ: Web_Server With this configuration, when you try to access from a client ( 10.0.14.5 ) to X.Y.128.4 the system hangs immediately. How can we debug this problem ? I think that this problem doesnt belong to misconfiguration. There is something wrong at in-kernel nat when packets reinjected to nat ? I can reproduce this situation. Regards, Thanks for your helps. Ozkan KIRIK From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 23 18:51:40 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 009FA1065686 for ; Wed, 23 Mar 2011 18:51:40 +0000 (UTC) (envelope-from kfl@xiplink.com) Received: from smtp151.iad.emailsrvr.com (smtp151.iad.emailsrvr.com [207.97.245.151]) by mx1.freebsd.org (Postfix) with ESMTP id B08518FC08 for ; Wed, 23 Mar 2011 18:51:39 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp45.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id AC05390FB1 for ; Wed, 23 Mar 2011 14:35:03 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp45.relay.iad1a.emailsrvr.com (Authenticated sender: kfodil-lemelin-AT-xiplink.com) with ESMTPSA id 8DC6C90F99 for ; Wed, 23 Mar 2011 14:35:03 -0400 (EDT) Message-ID: <4D8A3D4D.5080606@xiplink.com> Date: Wed, 23 Mar 2011 14:34:53 -0400 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ipfw tcpopt_match and m_pullup() X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 18:51:40 -0000 Hi, This is something that came up at work. While the ipfw code make sure the tcp header is contiguous in ipfw_chck by calling PULLUP_TO, the code does not guarantee 'contiguousity' of the TCP option space. This means that code that walks the option space in ipfw (namely tcpopts_match) could be falling off the edge of the mbuf container and lead to all sorts of problems. Following is a patch that fixed the problem for us and hopefully this gets pushed in this form or another to the freebsd tree for others to benefit. Best regards, Karim. #svn diff Index: ip_fw2.c =================================================================== --- ip_fw2.c (revision 218930) +++ ip_fw2.c (working copy) @@ -949,6 +949,11 @@ case IPPROTO_TCP: PULLUP_TO(hlen, ulp, struct tcphdr); + /* kfl: check 'contiguousity' of the option space */ + if (m->m_len < (hlen + (TCP(ulp)->th_off << 2))) { + if ((m = m_pullup(m, hlen+(TCP(ulp)->th_off << 2))) == NULL) + goto pullup_failed; + } dst_port = TCP(ulp)->th_dport; src_port = TCP(ulp)->th_sport; /* save flags for dynamic rules */ @@ -1117,6 +1122,11 @@ switch (proto) { case IPPROTO_TCP: PULLUP_TO(hlen, ulp, struct tcphdr); + /* kfl: check 'contiguousity' of the option space */ + if (m->m_len < (hlen + (TCP(ulp)->th_off << 2))) { + if ((m = m_pullup(m, hlen+(TCP(ulp)->th_off << 2))) == NULL) + goto pullup_failed; + } dst_port = TCP(ulp)->th_dport; src_port = TCP(ulp)->th_sport; /* save flags for dynamic rules */