From owner-freebsd-net@freebsd.org Fri Nov 27 09:18:09 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 A548EA36DFA for ; Fri, 27 Nov 2015 09:18:09 +0000 (UTC) (envelope-from ddb@neosystem.org) 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 6D7151983; Fri, 27 Nov 2015 09:18:09 +0000 (UTC) (envelope-from ddb@neosystem.org) Received: from mail.neosystem.cz (unknown [127.0.10.15]) by mail.neosystem.cz (Postfix) with ESMTP id 6AB32BD7D; Fri, 27 Nov 2015 10:18:06 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.neosystem.cz Received: from iron.sn.neosystem.cz (unknown [IPv6:2001:41d0:2:5ab8::100:107]) (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 9CE92BD77; Fri, 27 Nov 2015 10:18:05 +0100 (CET) Date: Fri, 27 Nov 2015 10:13:49 +0100 From: Daniel Bilik To: Gary Palmer Cc: freebsd-net@freebsd.org Subject: Re: Outgoing packets being sent via wrong interface Message-Id: <20151127101349.752c94090e78ca68cf0f81fc@neosystem.org> In-Reply-To: <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> <20151125122033.GB41119@in-addr.com> X-Mailer: Sylpheed 3.4.3 (GTK+ 2.24.28; amd64-portbld-freebsd10.2) 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: Fri, 27 Nov 2015 09:18:09 -0000 On Wed, 25 Nov 2015 12:20:33 +0000 Gary Palmer wrote: > route -n get As suggested by Kevin and Ryan, I set the router to drop redirects... net.inet.icmp.drop_redirect: 1 ... but it happened again today, and again affected host was 192.168.2.33. Routing and arp entries were correct. Output of "route -n get"... route to: 192.168.2.33 destination: 192.168.2.0 mask: 255.255.255.0 fib: 0 interface: re1 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0 ... has not changed during the problem. Interesting was ping result... PING 192.168.2.33 (192.168.2.33): 56 data bytes ping: sendto: Operation not permitted ping: sendto: Operation not permitted ... 64 bytes from 192.168.2.33: icmp_seq=11 ttl=128 time=0.593 ms ping: sendto: Operation not permitted ... 64 bytes from 192.168.2.33: icmp_seq=20 ttl=128 time=0.275 ms 64 bytes from 192.168.2.33: icmp_seq=21 ttl=128 time=0.251 ms ping: sendto: Operation not permitted ... 64 bytes from 192.168.2.33: icmp_seq=40 ttl=128 time=0.245 ms ping: sendto: Operation not permitted 64 bytes from 192.168.2.33: icmp_seq=42 ttl=128 time=7.111 ms ping: sendto: Operation not permitted ... --- 192.168.2.33 ping statistics --- 46 packets transmitted, 5 packets received, 89.1% packet loss It seems _some_ packets go the right interface (re1), but most try to go wrong (re0) and are dropped by pf... 00:00:01.066886 rule 53..16777216/0(match): block out on re0: 82.x.y.50 > 192.168.2.33: ICMP echo request, id 58628, seq 39, length 64 00:00:02.017874 rule 53..16777216/0(match): block out on re0: 82.x.y.50 > 192.168.2.33: ICMP echo request, id 58628, seq 41, length 64 00:00:02.069634 rule 53..16777216/0(match): block out on re0: 82.x.y.50 > 192.168.2.33: ICMP echo request, id 58628, seq 43, length 64 And again, refreshing default route (delete default / add default) resolved it... PING 192.168.2.33 (192.168.2.33): 56 data bytes 64 bytes from 192.168.2.33: icmp_seq=0 ttl=128 time=0.496 ms 64 bytes from 192.168.2.33: icmp_seq=1 ttl=128 time=0.226 ms 64 bytes from 192.168.2.33: icmp_seq=2 ttl=128 time=0.242 ms 64 bytes from 192.168.2.33: icmp_seq=3 ttl=128 time=0.226 ms -- Dan