From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 17:47:19 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CA5345F for ; Fri, 31 Oct 2014 17:47:19 +0000 (UTC) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1462B3C6 for ; Fri, 31 Oct 2014 17:47:19 +0000 (UTC) Received: by mail-oi0-f47.google.com with SMTP id a3so5364742oib.6 for ; Fri, 31 Oct 2014 10:47:18 -0700 (PDT) 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 :content-type; bh=bTyTuSc1U5BYgug7zlzyyLpsygR78mMD6/NCh9ZsUTQ=; b=ltAf4fTSWWq2cjnfToN/O28UFo/3ejJsB5Qx7gLblwqo+SqZFLZw09GyeUcHldVy8V TWYRFuSAjPfaRnHO7mOlUOaz+NygVcgX42EQjcnyXJZjshgIGJl1U5gPgyjgzrJi0gGC u1wulv42qJCIjpBUxGRUAjZjE5mSsKBp3lwXeA+9IPMihxSSapRlTfwoQC+gl8T4VTVg XnYuYbGemBvZeCxDmouNSB/W0en3flZaLFWpeZrmRpxvMWqUPaoOWsQW4bXQGdeZi65G 30AR4tFtVohqQRdV1BZA1n8W5c1pKJdhbUWhcIzgCrJvaoV/8Nle+0cYpYElziCMkyoH NXSA== X-Received: by 10.60.132.7 with SMTP id oq7mr2842736oeb.61.1414777638333; Fri, 31 Oct 2014 10:47:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.93.40 with HTTP; Fri, 31 Oct 2014 10:46:58 -0700 (PDT) In-Reply-To: References: <009c01cff388$29fe7ec0$7dfb7c40$@gmail.com> From: Raimundo Santos Date: Fri, 31 Oct 2014 15:46:58 -0200 Message-ID: Subject: Re: ipfw fwd duplicating packets in 9.3-RELEASE To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 17:47:19 -0000 For documentation: I do not know why or how, but after trying to reproduce the same strange behaviour, it did not happen. This was after restarting all the test environment. Weird. Sorry for take your time with this strange mess. Regards, Raimundo Santos On 29 October 2014 14:30, Raimundo Santos wrote: > > > On 29 October 2014 12:53, bycn82 wrote: > > > > Hi, > > I cannot help to point out when the ICMP packet was duplicated and > transfer > > via 2 different links, If it happens in my machine, I will call this > feature > > "multi-homing". > > > That is a bit off topic, but how and undesired behaviour could be a > feature? It is not only undesired, but it is also undocumented. > > If I filter incoming packtes, I got it sent to the original and to the fwd > destinations, by my tests. I can not see how it is multi-homing. > > What I know by multi-homing is: two or more interconnections with the same > other network, or to the Internet. It implies more care to the outgoing and > incoming paths. Who leaves from link 1 will enter via link 1? It is ok to > happen that way? Only the context can say that. > > In my case the packet not only get out via two different links, but it is > reaching two *different* machines in different networks. > > > > > But what I want to say is the firewall rule > > fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 out xmit em1 > > You can remove the "out" because "xmit" will check the "out interface". > > Thank you for the clarification. > > > > > > > Regards, > > Bycn82 > > > Regards, > Raimundo Santos > > > > > > > > -----Original Message----- > > From: owner-freebsd-net@freebsd.org [mailto: > owner-freebsd-net@freebsd.org] > > On Behalf Of Raimundo Santos > > Sent: Tuesday, 28 October, 2014 3:32 PM > > To: freebsd-net@freebsd.org > > Subject: ipfw fwd duplicating packets in 9.3-RELEASE > > > > Hello list! > > > > I was testing the behaviour of fwd in ipfw from FreeBSd 9.3-RELEASE, > latest > > updates, GENERIC kernel, in this setup: > > > > 1x FreeBSD 9.3 as router, with 3 network interfaces 5x OpenBSD 5.5 as > > network machines, each one connected to FreeBSD via one port. > > > > It is a virtual env. > > > > FreeBSD em0 (192.168.0.1) -> OpenBSD#1 em0 (192.168.0.2) FreeBSD em1 > > (192.168.1.1) -> OpenBSD#2 em0 (192.168.1.2) FreeBSD em2 (192.168.2.1) -> > > OpenBSD#3 em0 (192.168.2.2) FreeBSD em3 (192.168.3.1) -> OpenBSD#4 em0 > > (192.168.3.2) FreeBSD em4 (192.168.4.1) -> OpenBSD#5 em1 (192.168.4.2) > > > > ipfw rule: > > > > fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 in recv em4 > > > > Then a ping 192.168.1.2 was issued from OpenBSD#5. > > > > Interestingly, this rule put a packet on em0 and em1 in FreeBSD. The > packet > > successfully arrived at OpenBSD#1, where it was discarded, and at > OpenBSD#2, > > where it got its reply. > > > > Only these combinations of interface direction do not duplicate the > packet: > > out xmit > > > > fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 out xmit em1 > > > > and > > > > fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 out via em1 > > > > Even out recv em4 xmit em1 leads to packet duplication. > > > > I think that it is a bad thing for PBR. As I can see from these tests, I > can > > not use all the options to do PBR. > > > > In my real needs I have to: > > > > 1. let web traffic flow to an cache appliance (from internal network to > > cache, from internet to cache) > > > > 2. do NAT for the internal network under three different links > > > > In theory, fwd + in kernel NAT + one_pass=0 could solve the problem. But > I > > am hitting my head in the wall for almost three weeks on this, only now I > > have the time to test in a more clear way. First I blamed the NAT, after > > that the one_pass=0, and now, with these results, well... > > > > Someone has an explanation about it? Something related to > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=129036? > > > > For my real needs, I figured out that it works with > > > > <...before NAT aliasing...> > > fwd CACHE_IP proto tcp src-ip table(INT) dst-port 80 out recv INT_IFACE > > <...after NAT dealiasing...> fwd CACHE_IP proto tcp dst-ip table(INT) > > src-port 80 out recv EXT_IFACE > > > > But I am not confident that it will remains in good shape without knowing > > exactly why fwd behaves that way. > > > > Thank you in advance for your time, > > Raimundo Santos > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > >