From owner-freebsd-net@freebsd.org Sun Nov 22 12:06:15 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 29CA6A35F9A for ; Sun, 22 Nov 2015 12:06:15 +0000 (UTC) (envelope-from daniel.bilik@neosystem.cz) Received: from mail.neosystem.cz (mail.neosystem.cz [IPv6:2001:41d0:2:5ab8::10:15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E7E4E1348; Sun, 22 Nov 2015 12:06:14 +0000 (UTC) (envelope-from daniel.bilik@neosystem.cz) Received: from mail.neosystem.cz (unknown [127.0.10.15]) by mail.neosystem.cz (Postfix) with ESMTP id A7BAD74C; Sun, 22 Nov 2015 13:06:11 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.neosystem.cz Received: from dragon.sn.neosystem.cz (unknown [IPv6:2001:41d0:2:5ab8::100:101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.neosystem.cz (Postfix) with ESMTPSA id 07793746; Sun, 22 Nov 2015 13:06:10 +0100 (CET) Date: Sun, 22 Nov 2015 13:02:40 +0100 From: Daniel Bilik To: Kristof Provost Cc: freebsd-net@freebsd.org Subject: Re: Outgoing packets being sent via wrong interface Message-Id: <20151122130240.165a50286cbaa9288ffc063b@neosystem.cz> In-Reply-To: <20151121212043.GC2307@vega.codepro.be> References: <20151120155511.5fb0f3b07228a0c829fa223f@neosystem.org> <20151120163431.3449a473db9de23576d3a4b4@neosystem.org> <20151121212043.GC2307@vega.codepro.be> X-Mailer: Sylpheed 3.4.3 (GTK+ 2.24.28; x86_64-portbld-dragonfly4.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Sun, 22 Nov 2015 12:06:15 -0000 On Sat, 21 Nov 2015 22:20:43 +0100 Kristof Provost wrote: >> 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. Well, even though pf may play some role in the problem, I tend to suspect the routing table as the main trigger. There are several facts to support this... 1. after reboot, the router runs fine, even with this "double nat" rule 2. this "double nat" rule was also present on the router when it was running 9-stable, working flawlessly for years 3. when the problems start, there already is one or more "hits" to routing table (by a previously mentioned cron task that updates default route to keep the connectivity), ie. the problems may or may not start only after touching the routing table 4. it seems that touching routing table can also "cure" the problem: last week I noticed the router was unable to make tcp connections to one host over vpn - same problem, it was pushing packets via re0 instead of tap0, but yesterday I've found the problem is gone, without any reboot or other intervention, and surprise... there was short connectivity problem at the beginning of this week, thus default route was changed twice > I don't have the time to dig into this right away. Could you create a PR > and cc me to it? Created, bug id 204735. Thank you. -- Dan