From owner-freebsd-net@freebsd.org Sat Nov 21 21:20:47 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 050D6A34089 for ; Sat, 21 Nov 2015 21:20:47 +0000 (UTC) (envelope-from kp@vega.codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C13B919B6 for ; Sat, 21 Nov 2015 21:20:46 +0000 (UTC) (envelope-from kp@vega.codepro.be) Received: from vega.codepro.be (unknown [172.16.1.3]) by venus.codepro.be (Postfix) with ESMTP id 519DF7661; Sat, 21 Nov 2015 22:20:43 +0100 (CET) Received: by vega.codepro.be (Postfix, from userid 1001) id 4B7757FC6F; Sat, 21 Nov 2015 22:20:43 +0100 (CET) Date: Sat, 21 Nov 2015 22:20:43 +0100 From: Kristof Provost To: Daniel Bilik Cc: freebsd-net@freebsd.org Subject: Re: Outgoing packets being sent via wrong interface Message-ID: <20151121212043.GC2307@vega.codepro.be> References: <20151120155511.5fb0f3b07228a0c829fa223f@neosystem.org> <20151120163431.3449a473db9de23576d3a4b4@neosystem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20151120163431.3449a473db9de23576d3a4b4@neosystem.org> X-Checked-By-NSA: Probably User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2015 21:20:47 -0000 On 2015-11-20 16:34:31 (+0100), Daniel Bilik wrote: > On Fri, 20 Nov 2015 16:18:10 +0100 > Kristof Provost wrote: > > > Can you post your pf rules too? > > Sure, pf.conf attached. > Thanks. As a first guess, I think the origin of the problem might be related to the double nat rule you've got. nat on $ext_if proto udp from $switchboard to 188.x.y.0/24 -> $ext_addr static-port nat on $ext_if from $int_net to any -> $ext_addr Packets that hit the first rule would also match the second one. In principle the last match should win and everything should be fine, but NAT is handled differently from 'normal' rules, so perhaps there's a bug there. I don't have the time to dig into this right away. Could you create a PR and cc me to it? Thanks, Kristof