From owner-freebsd-current@freebsd.org Thu Dec 10 23:55:00 2015 Return-Path: Delivered-To: freebsd-current@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 A58CA9D60A4 for ; Thu, 10 Dec 2015 23:55:00 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 456C517C0 for ; Thu, 10 Dec 2015 23:54:59 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074425-f793c6d000006975-4f-566a0f9ddee1 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id D1.77.26997.E9F0A665; Thu, 10 Dec 2015 18:49:50 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id tBANnnqU028904; Thu, 10 Dec 2015 18:49:49 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tBANnjsp009322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Dec 2015 18:49:48 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id tBANnjxA008987; Thu, 10 Dec 2015 18:49:45 -0500 (EST) Date: Thu, 10 Dec 2015 18:49:45 -0500 (EST) From: Benjamin Kaduk To: Rick Macklem cc: freebsd-current Subject: Re: RPC request sent to 127.0.0.1 becomes from other IP on machine In-Reply-To: <521574245.126601980.1449754639530.JavaMail.zimbra@uoguelph.ca> Message-ID: References: <521574245.126601980.1449754639530.JavaMail.zimbra@uoguelph.ca> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrTuPPyvM4G4bh8WcNx+YLB4uu8bk wOQx49N8Fo/fm/cyBTBFcdmkpOZklqUW6dslcGUcPXyRsWAzT8XHi41MDYyPObsYOTkkBEwk Hj0+yQ5hi0lcuLeerYuRi0NIYDGTxNSLU1khnI2MElP2HWSHcA4xScxduZIZwmlglNg85TAb SD+LgLbE9umfmUBsNgEViZlvNoLFRQTUJTav7mcGsZkFDCVerrsHtk9YwFti4rnpYDangI/E sxdXwOp5BRwl9lyZzgpiCwHVPGzsA5spKqAjsXr/FBaIGkGJkzOfsEDM1JJYPn0bywRGwVlI UrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3StdDLzSzRS00p3cQIClZ2F9UdjBMOKR1i FOBgVOLh9WDLChNiTSwrrsw9xCjJwaQkyjvrW2aYEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHe CG6gct6UxMqq1KJ8mJQ0B4uSOO/cL75hQgLpiSWp2ampBalFMFkZDg4lCd4CPqBGwaLU9NSK tMycEoQ0EwcnyHAeoOGyIDW8xQWJucWZ6RD5U4yKUuK8ASAJAZBERmkeXC84mexmUn3FKA70 ijBvL0gVDzARwXW/AhrMBDT4y5V0kMEliQgpqQZGybQFRWbHe5wnMr3m2LOI5depxRan/l9b +fipMseusnu3Vxwz0herzrirPk1YV8hv0umEd+JTE5nmflWY3rk0TjYi2CBnTeOWwitflSZE 6Pi/m3Z0+asLdWXNfB9+x51dKbbuq7t5j8bpQ4vUK7QNbiw8yjq3cOnTdR/99jyqzFQqKLvK 1pUwUYmlOCPRUIu5qDgRAO4V0SsBAwAA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 23:55:00 -0000 On Thu, 10 Dec 2015, Rick Macklem wrote: > Hi, > > Mark has reported a problem via email where the nfsuserd daemon sees > requests coming from an IP# assigned to the machine instead of 127.0.0.1. > Here's a snippet from his message: > Ok, I have Plex in a jail and when I scan the remote NFS file share the > *local* server's nfsuserd spams the logs. > Spamming the logs refers to the messages nfsuserd generates when it gets > a request from an address other than 127.0.0.1. > > I think the best solution is to switch nfsuserd over to using an AF_LOCAL > socket like the gssd uses, but that will take a little coding and probably > won't be MFCable. > > I've sent him the attached patch to try as a workaround. > > Does anyone happen to know under what circumstances the address 127.0.0.1 > gets replaced? My memory is quite hazy on this subject, but I think that outbound traffic from a jail is not permitted to use the system loopback address 127.0.0.1; traffic from this address within a jail gets replace with the jail's primary IP address. It is possible to specify an alternate loopback address for use within the jail (e.g., 127.0.0.2) and if that alternate address is only bound within the jail, it can be used for outgoing traffic to the host. See jail.conf(5); I appear to have something like: kduck { host.hostname = "kduck.mit.edu"; ip4.addr = lo0|127.0.0.2, 18.18.0.52; [...] } Note that there may be some additional magic about the primary address of the jail being first (or last?) in the list of addresses. -Ben