From owner-freebsd-net@freebsd.org Wed Nov 25 12:20:35 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 73697A37454 for ; Wed, 25 Nov 2015 12:20:35 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (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 365A714D2; Wed, 25 Nov 2015 12:20:35 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by mail.in-addr.com with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1a1Z3p-0004eR-3g; Wed, 25 Nov 2015 12:20:33 +0000 Date: Wed, 25 Nov 2015 12:20:33 +0000 From: Gary Palmer To: Daniel Bilik Cc: Kristof Provost , freebsd-net@freebsd.org Subject: Re: Outgoing packets being sent via wrong interface Message-ID: <20151125122033.GB41119@in-addr.com> References: <20151120155511.5fb0f3b07228a0c829fa223f@neosystem.org> <20151120163431.3449a473db9de23576d3a4b4@neosystem.org> <20151121212043.GC2307@vega.codepro.be> <20151122130240.165a50286cbaa9288ffc063b@neosystem.cz> <20151125092145.e93151af70085c2b3393f149@neosystem.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151125092145.e93151af70085c2b3393f149@neosystem.cz> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false 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 12:20:35 -0000 On Wed, Nov 25, 2015 at 09:21:45AM +0100, Daniel Bilik wrote: > 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. When the problem happens, what does the output of route -n get show? It would also be worth checking the arp table. Gary