From owner-freebsd-ipfw@FreeBSD.ORG Mon Jan 13 11:06:46 2014 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3610603 for ; Mon, 13 Jan 2014 11:06:46 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B6D471145 for ; Mon, 13 Jan 2014 11:06:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s0DB6kUB095867 for ; Mon, 13 Jan 2014 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0DB6kow095865 for freebsd-ipfw@FreeBSD.org; Mon, 13 Jan 2014 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 13 Jan 2014 11:06:46 GMT Message-Id: <201401131106.s0DB6kow095865@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 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 11:06:47 -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/180731 ipfw [ipfw] problem with displaying 255.255.255.255 address o kern/180729 ipfw [ipfw] ipfw nat show empty output o kern/178482 ipfw [ipfw] logging problem from vnet jail o kern/178480 ipfw [ipfw] dynamically loaded ipfw with a vimage kernel do o kern/178317 ipfw [ipfw] ipfw options need to specifed in specific order o kern/177948 ipfw [ipfw] ipfw fails to parse port ranges (p1-p2) for udp o kern/176503 ipfw [ipfw] ipfw layer2 problem o conf/167822 ipfw [ipfw] [patch] start script doesn't load firewall_type o kern/166406 ipfw [ipfw] ipfw does not set ALTQ identifier for ipv6 traf o kern/165939 ipfw [ipfw] bug: incomplete firewall rules loaded if tables o kern/165190 ipfw [ipfw] [lo] [patch] loopback interface is not marking o kern/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets o kern/157689 ipfw [ipfw] ipfw nat config does not accept nonexistent int f kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw [ipfw] does not support specifying rules with ICMP cod o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. f kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l f kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from 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/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/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/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes s kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw 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 42 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Thu Jan 16 11:20:01 2014 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 803C2FE5 for ; Thu, 16 Jan 2014 11:20:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 525601D11 for ; Thu, 16 Jan 2014 11:20:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s0GBK1An090358 for ; Thu, 16 Jan 2014 11:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0GBK19O090357; Thu, 16 Jan 2014 11:20:01 GMT (envelope-from gnats) Date: Thu, 16 Jan 2014 11:20:01 GMT Message-Id: <201401161120.s0GBK19O090357@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org Cc: From: "Alexander V. Chernikov" Subject: Re: kern/122963: [ipfw] tcpdump does not show packets redirected by 'ipfw fwd' on proper interface X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Alexander V. Chernikov" List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 11:20:01 -0000 The following reply was made to PR kern/122963; it has been noted by GNATS. From: "Alexander V. Chernikov" To: bug-followup@FreeBSD.org, zuborg@advancedhosters.com Cc: Subject: Re: kern/122963: [ipfw] tcpdump does not show packets redirected by 'ipfw fwd' on proper interface Date: Thu, 16 Jan 2014 15:09:46 +0400 This is not a bug. You're adding fwd rule which forwards outgoing packet back to the local system (since fwd address is em0 address). That's why you're not seeing packet on the wire. From owner-freebsd-ipfw@FreeBSD.ORG Thu Jan 16 11:37:43 2014 Return-Path: Delivered-To: freebsd-ipfw@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 442C1436; Thu, 16 Jan 2014 11:37:43 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 18E791E98; Thu, 16 Jan 2014 11:37:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s0GBbgiv094516; Thu, 16 Jan 2014 11:37:42 GMT (envelope-from melifaro@freefall.freebsd.org) Received: (from melifaro@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0GBbgh4094515; Thu, 16 Jan 2014 11:37:42 GMT (envelope-from melifaro) Date: Thu, 16 Jan 2014 11:37:42 GMT Message-Id: <201401161137.s0GBbgh4094515@freefall.freebsd.org> To: melifaro@FreeBSD.org, freebsd-ipfw@FreeBSD.org, freebsd-net@FreeBSD.org From: melifaro@FreeBSD.org Subject: Re: kern/129036: [ipfw] 'ipfw fwd' does not change outgoing interface name X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 11:37:43 -0000 Synopsis: [ipfw] 'ipfw fwd' does not change outgoing interface name Responsible-Changed-From-To: freebsd-ipfw->freebsd-net Responsible-Changed-By: melifaro Responsible-Changed-When: Thu Jan 16 11:31:08 UTC 2014 Responsible-Changed-Why: Reclassify. This problem is not related to ipfw: ipfw(4) sets M_IP_NEXTHOP & adds PACKET_TAG_IPFORWARD on ingress and returns. ip_input() sees M_IP_NEXTHOP and passes packet to ip_forward() which performs routing decision and calls ip_output(). Finally, ip_ouput() calls PFIL hook with ifp determined by ip_forward() and checks M_IP_NEXTHOP _after_ that. http://www.freebsd.org/cgi/query-pr.cgi?pr=129036 From owner-freebsd-ipfw@FreeBSD.ORG Thu Jan 16 23:02:09 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C9591DE; Thu, 16 Jan 2014 23:02:09 +0000 (UTC) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E96941285; Thu, 16 Jan 2014 23:02:08 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id o6so3750494oag.11 for ; Thu, 16 Jan 2014 15:02:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MvKng5108Bv1LRJBBj7iB6P/9O/4+hqVdBkylMoJgTI=; b=C5NCfJ1WgvutR1kvbLqShkt0/wO4ewLEwawbWiIdXWoejwoDPG/Kc/TGgdL8eBGTPs yUCUUxnxXy1WpNXvyUi8x4UjpKHoMUgZvWjWnnEs6D+cYuOpa7DcakVxSqbbSO6wUBxy RvFDHD7Z0IaONiLEhw793z+H7KfOHynMeYO2b6kGygD2wQA/l0in8qWTJE8wfj6q4rNG 6bu66usPxuH7dtpGBPwffvh81Xw+FjfsCJwboC77ZnOOSyNAWA5/0JIbl/F6V83GHCic /FcTtrDaeW8aTbEKLXlUB9VVLLcyi6gRpnHzoExZEVawdpchS6BM0w1F7vUnFlK2H8UZ lSFQ== X-Received: by 10.60.16.230 with SMTP id j6mr9401374oed.47.1389913328063; Thu, 16 Jan 2014 15:02:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.166.165 with HTTP; Thu, 16 Jan 2014 15:01:48 -0800 (PST) In-Reply-To: <201401161120.s0GBK19O090357@freefall.freebsd.org> References: <201401161120.s0GBK19O090357@freefall.freebsd.org> From: n j Date: Fri, 17 Jan 2014 00:01:48 +0100 Message-ID: Subject: Re: kern/122963: [ipfw] tcpdump does not show packets redirected by 'ipfw fwd' on proper interface To: "Alexander V. Chernikov" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 23:02:09 -0000 Ok, it's been a while since I posted that feedback to the PR, so I don't really remember all the details, but I probably get what you're saying. Let me go over my original problem: A program ("MUX") listens on port 443 on the server. It receives requests from clients and forwards those packets to another program ("SERVER") listening on same server port 8443. MUX is using transparent forwarding so the SERVER receives packets with the original address and port intact. Obviously, when SERVER makes a reply, it sends the reply directly to the original client due to source addresses having been transparently forwarded. To fix that, an 'ipfw fwd' rule catches these outgoing packets and redirects the packets back to MUX. This setup works fine. The problem arose while I was debugging some issues with the programs and that was when I noticed that in the tcpdump I only see the following traffic: (tcpdump on public interface) CLIENT:PORT --> MUX:443 MUX:443 --> CLIENT:PORT and (tcpdump on loopback) MUX (posing as CLIENT:PORT) --> SERVER:8443 but there was no traffic going back from SERVER:8443 to CLIENT:PORT (actually ending in MUX due to 'ipfw fwd' rule). As I said above, I probably understand why it's not there. I can see fwd rule in ipfw logs showing the packet going from SERVER:8443 to CLIENT:PORT out via public interface, but it actually doesn't reach the wire and tcpdump because fwd rule snatches it before it can go out and forwards it to MUX so that MUX can send it out. However, I still feel as if there should be a trace of that packet somewhere in the tcpdump as the packet after all leaves one userland program (SERVER) and enters another userland program (MUX). It'd certainly help to see all packets (i.e. both connections and all 4 directions) when debugging problems with a setup like the one I described. Am I missing something important here? Regards, -- Nino On Thu, Jan 16, 2014 at 12:20 PM, Alexander V. Chernikov < melifaro@freebsd.org> wrote: > The following reply was made to PR kern/122963; it has been noted by GNATS. > > From: "Alexander V. Chernikov" > To: bug-followup@FreeBSD.org, zuborg@advancedhosters.com > Cc: > Subject: Re: kern/122963: [ipfw] tcpdump does not show packets redirected > by 'ipfw fwd' on proper interface > Date: Thu, 16 Jan 2014 15:09:46 +0400 > > This is not a bug. > > You're adding fwd rule which forwards outgoing packet back to the local > system (since fwd address is em0 address). > That's why you're not seeing packet on the wire. > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > From owner-freebsd-ipfw@FreeBSD.ORG Fri Jan 17 19:32:06 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85C17F00 for ; Fri, 17 Jan 2014 19:32:06 +0000 (UTC) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 438A812C6 for ; Fri, 17 Jan 2014 19:32:06 +0000 (UTC) Received: by mail-ve0-f173.google.com with SMTP id oz11so632667veb.32 for ; Fri, 17 Jan 2014 11:32:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=zMm/RKWtNL3l07y5S+gigtsdDpWvhvGFWSdbhh1Zsm0=; b=D9CNdiIs94fHcNDCGs6Pmspha/Gkzf1rHTkmidzA50Z2cIlH4pqNFv0QQsy42gDWaE 2zhtKpwYJwltEpa6ljTqd4Z1LnFEFEOiun5BeB0uNT8A6U4JLoK0yY+PbxzfY84nE/L6 bjKbSZkFAZoju18D/oAGdi8xdk+/VHhG/ZJO5SC0BStVOuiuctMF56LbSO2CP09voMQD aeHlsIOZOFk7tYVs+G7rpyCddVRYUgukYfC5aPRexoLnnZCBIq0AoLZOso/2bAvrwgkF dlNxgXKYlc2q+b+LexYCVmRiUL1m+jMFP2fGCrg513A6op5dlUh/u+zuQb2fq1cWQtOF mhog== MIME-Version: 1.0 X-Received: by 10.220.183.202 with SMTP id ch10mr6396vcb.36.1389987125371; Fri, 17 Jan 2014 11:32:05 -0800 (PST) Sender: ndenev@gmail.com Received: by 10.220.78.84 with HTTP; Fri, 17 Jan 2014 11:32:05 -0800 (PST) In-Reply-To: <52CA1AB2.8050601@saltant.com> References: <52CA1AB2.8050601@saltant.com> Date: Fri, 17 Jan 2014 19:32:05 +0000 X-Google-Sender-Auth: VUHXfHCqENpkFeu6ZS99eqjxdXc Message-ID: Subject: Re: ipfw rule to match IPv4-in-IPv6 tunneled packets syntax problem From: Nikolay Denev To: "John W. O'Brien" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 19:32:06 -0000 On Mon, Jan 6, 2014 at 2:53 AM, John W. O'Brien wrote: > Hello freebsd-ipfw@, > > I just tripped over what seems to be a syntax bug and need some help > understanding it well enough to submit a PR (or to be dissuaded from > doing so). A quick look through all PRs matching 'ipfw', open and > closed, does not reveal a clear duplicate. > > Let's say my machine has a physical interface, em0, with IPv4 address > 192.0.2.1, and a tunneling peer with IPv4 address 198.51.100.2. I also > have gif0 configured with these tunnel end points and an inner IPv6 > address (which I do not believe is relevant). > > I have the following interaction with the machine. > > % ipfw add 1000 allow ip4 from 198.51.100.2 to 192.0.2.1 ipv6 > 1000 allow ip4 from 198.51.100.2 to 192.0.2.1 ip6 > % ipfw add 2000 allow ip4 from 198.51.100.2 to 192.0.2.1 proto ipv6 > 2000 allow ip4 from 198.51.100.2 to 192.0.2.1 ipv6 > > Notice that when I say "ipv6", ipfw responds "ip6", but when I say > "proto ipv6", ipfw responds "ipv6". Is this an unintended exception, or > the unintended consequence of grammar implications I just don't fully > understand? > > Next my peer sends me some tunneled traffic---each packet incident upon > em0 starts with an IPv4 header with the proto field equal to 41, > followed by an IPv6 header---and I check the rule counters. Rule 1000 > has zero hits, but rule 2000 has all the hits. > > What would rule 1000 match? > > This is on 9.2-STABLE r260112. > > Regards, > John > Just to say me too. I've banged my head a bit exactly because of this a few days ago. It was really confusing : ipfw add allow ip6 from any to any -> shows ip6 ipfw add allow ipv6 from any to any -> shows ip6 ipfw add allow 41 from any to any -> shows ipv6 While it looks like it's tersely documented in ipfw(8): ip4 | ipv4 Matches IPv4 packets. ip6 | ipv6 Matches IPv6 packets. ip | all Matches any packet. The ipv6 in proto option will be treated as inner protocol. And, the ipv4 is not available in proto option. It's still confusing. --Nikolay