From owner-freebsd-hackers@freebsd.org Sun Jun 25 23:37:42 2017 Return-Path: Delivered-To: freebsd-hackers@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 B07CED9C7AE for ; Sun, 25 Jun 2017 23:37:42 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from hermes.heuristicsystems.com.au (hermes.heuristicsystems.com.au [203.41.22.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.heuristicsystems.com.au", Issuer "Heuristic Systems Type 4 Host CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CEE2881B1F for ; Sun, 25 Jun 2017 23:37:40 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from [10.0.5.3] (ewsw01.hs [10.0.5.3]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.15.2/8.15.2) with ESMTPSA id v5PNbNLS012299 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 26 Jun 2017 09:37:28 +1000 (AEST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) X-Authentication-Warning: b3.hs: Host ewsw01.hs [10.0.5.3] claimed to be [10.0.5.3] Subject: Re: Kernel panic in nfsv4_loadattr To: Rick Macklem , "freebsd-hackers@freebsd.org" References: <118188c1-6507-fd83-9d6e-94e304521011@physik.tu-berlin.de> From: Dewayne Geraghty Message-ID: <41f2553c-a9a6-f997-4b0a-1fe6c7603835@heuristicsystems.com.au> Date: Mon, 26 Jun 2017 09:37:18 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-AU Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2017 23:37:42 -0000 Rick, A minor point. Jails don't break/disable 127.0.0.1, though it certainly changes behaviour. 127.0.0.1 within a jail context is reassigned the first IP that is defined in jail.conf (or passed to the jail during creation). So for example during a ping from a jail with its first ip 10.0.7.96 defined for em1, when a ping occurs within the jail # ping -c 1 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=42 time=0.039 ms the tcpdump of lo0 (from the host system), becomes: 09:16:23.699627 IP 10.0.7.96 > 127.0.0.1: ICMP echo request, id 52014, seq 0, length 64 09:16:23.699671 IP 127.0.0.1 > 10.0.7.96: ICMP echo reply, id 52014, seq 0, length 64 Even though the jail itself has lo0 defined as lo0: flags=8049 metric 0 mtu 16384 options=600003 groups: lo (ie no explicit 127 subnet). This has significant security issues and requires careful firewalling attention. As an aside, a reasonable approach is to define an ip to lo0 (for the jail), then, from a jail with first ip 10.0.7.91 the # ping -c 1 127.0.0.1 becomes 09:25:23.348288 IP 127.1.5.91 > 127.0.0.1: ICMP echo request, id 25647, seq 0, length 64 09:25:23.348319 IP 127.0.0.1 > 127.1.5.91: ICMP echo reply, id 25647, seq 0, length 64 A much better outcome - in terms of not needing to allow a possibly external IP from accessing lo0 :) This may provide further insight into jail/network issues? Cheers. PS Oh and the first IP of a jail also becomes the default route for it