From owner-freebsd-net@freebsd.org Wed Nov 25 08:25:00 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 8E5D1A37A1C for ; Wed, 25 Nov 2015 08:25:00 +0000 (UTC) (envelope-from daniel.bilik@neosystem.cz) Received: from mail.neosystem.cz (mail.neosystem.cz [94.23.169.88]) (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 55D8C190D; Wed, 25 Nov 2015 08:24:59 +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 57990B8C7; Wed, 25 Nov 2015 09:24:51 +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 76B2DB8C1; Wed, 25 Nov 2015 09:24:50 +0100 (CET) Date: Wed, 25 Nov 2015 09:21:45 +0100 From: Daniel Bilik To: Kristof Provost Cc: freebsd-net@freebsd.org Subject: Re: Outgoing packets being sent via wrong interface Message-Id: <20151125092145.e93151af70085c2b3393f149@neosystem.cz> In-Reply-To: <20151122130240.165a50286cbaa9288ffc063b@neosystem.cz> References: <20151120155511.5fb0f3b07228a0c829fa223f@neosystem.org> <20151120163431.3449a473db9de23576d3a4b4@neosystem.org> <20151121212043.GC2307@vega.codepro.be> <20151122130240.165a50286cbaa9288ffc063b@neosystem.cz> Organization: neosystem.cz 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: Wed, 25 Nov 2015 08:25:00 -0000 On Sun, 22 Nov 2015 13:02:40 +0100 Daniel Bilik wrote: > 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... It happened again, yesterday, and I can now definitely confirm that it's related to default route. In this case, affected address was 192.168.2.33. This host was unable to connect to 192.168.2.15 (jail on the router), and router itself was unable to even ping the affected host... PING 192.168.2.33 (192.168.2.33): 56 data bytes ping: sendto: Operation not permitted ping: sendto: Operation not permitted ... because again it was pushing outgoing packets wrong way, via public interface, where it's dropped by pf... 00:00:07.091814 rule 53..16777216/0(match): block out on re0: 82.x.y.50 > 192.168.2.33: ICMP echo request, id 12037, seq 0, length 64 00:00:01.011536 rule 53..16777216/0(match): block out on re0: 82.x.y.50 > 192.168.2.33: ICMP echo request, id 12037, seq 1, length 64 I've tried to just delete default route and enter it back to routing table. In one tmux session ping was running, in another session I've performed this... # route delete default ; sleep 1 ; route add default 82.x.y.29 ... and voila, ping started to communicate with affected host... ping: sendto: Operation not permitted ping: sendto: Operation not permitted 64 bytes from 192.168.2.33: icmp_seq=12 ttl=128 time=0.535 ms 64 bytes from 192.168.2.33: icmp_seq=13 ttl=128 time=0.264 ms Touching nothing else (pf etc.), not rebooting, just "refreshing" the default route entry, and the problem disappeared. -- Dan