From owner-freebsd-questions@FreeBSD.ORG Wed Jun 17 18:28:16 2009 Return-Path: Delivered-To: questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 327421065674 for ; Wed, 17 Jun 2009 18:28:16 +0000 (UTC) (envelope-from nvass9573@gmx.com) Received: from mail.gmx.com (unknown [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id 8B8D68FC12 for ; Wed, 17 Jun 2009 18:28:15 +0000 (UTC) (envelope-from nvass9573@gmx.com) Received: (qmail invoked by alias); 17 Jun 2009 18:28:13 -0000 Received: from ipa255.25.107.79.tellas.gr (EHLO [192.168.254.1]) [79.107.25.255] by mail.gmx.com (mp-eu003) with SMTP; 17 Jun 2009 20:28:13 +0200 X-Authenticated: #46156728 X-Provags-ID: V01U2FsdGVkX182Ap1egPI24pZADeNEu8guQpPx37yZGJDelxvmsq 1W62XLh4Lh9u7B Message-ID: <4A3935A3.1000600@gmx.com> Date: Wed, 17 Jun 2009 21:27:47 +0300 From: Nikos Vassiliadis User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Erik Norgaard References: <4A37F2B7.6000505@locolomo.org> <4A38A8A6.4090702@locolomo.org> <4A38EBE4.9040009@ibctech.ca> <4A38FF83.3010501@locolomo.org> In-Reply-To: <4A38FF83.3010501@locolomo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.46 Cc: questions@freebsd.org, Steve Bertrand Subject: Re: Problem with jail connecting out X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 18:28:16 -0000 Erik Norgaard wrote: > Steve Bertrand wrote: >> Erik Norgaard wrote: >>> Erik Norgaard wrote: >>> >>>> I have no problem connecting from the host to the jail, but the other >>>> way around doesn't work. >>>> >>>> Also, related, how do I configure multiple interfaces in a jail? >>> Second problem solved, starting jail with >>> >>> # jail /var/jail jail 127.0.0.2,172.16.0.2 /bin/sh /etc/rc >>> >>> So, now I have: >>> >>> vr1: flags=8943 metric 0 >>> mtu 1500 >>> options=2808 >>> ether 00:40:63:ee:97:f1 >>> inet 172.16.0.2 netmask 0xffffffff broadcast 172.16.0.2 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> lo0: flags=8049 metric 0 mtu 16384 >>> inet 127.0.0.2 netmask 0xffffffff >>> >>> Now, I can connect out on vr1 to 172.16.0.1, but not on lo0 to >>> 127.0.0.1. Any suggestions what might be wrong? >> >> I don't think that it is a wise idea to be using the loopback address >> space to route packets outside of the OS, and it is even possible that >> some implementations forbid this behaviour (don't quote me on that). > > I have read some recommendations not to use the loopback interface > without any real explanation, I don't see why it shouldn't work with a > different IP as for other interfaces - or a cloned loopback. It's the 127/8 that is special, that is, it's treated specially by the network stack and is dropped when coming from an interface other than a loopback one. In general, packets that coming into/leave the box that have a loopback source/destination address have nothing special and can be used as any other address. >> If you want a loopback to be a receive interface, you should clone off a >> second one (lo1), and assign an IP address to it that was not designed >> to be short circuited within the host, like this: >> >> % grep lo10 /etc/rc.conf >> >> cloned_interfaces="lo1 lo3 lo10 ...etc >> >> # lo10 (IPv4 iBGP loopback, advertised by OSPF) >> ifconfig_lo10="UP" >> ifconfig_lo10="inet 172.16.104.8 netmask 255.255.255.255" >> >>>> From RFC 1700: >> >> (g) {127, } >> >> Internal host loopback address. Should never appear outside >> a host. > > It won't. It's intended to be stricly local on the internal loopback > interface. > > The idea is to use the loopback interface for connecting between the > jail and the host while not exposing the jail to the exterior. > > Basically, I'm trying to setup a jail for my imap server to migrate my > mail from the existing server, a last resort clumsy way of upgrading the > Berkeley DB. Then a script connecting to both services can create > accounts, folders and copy the mail to the new service. > > The idea is that this way I could do it transparently - well, that's the > theory. Your theory is correct, and it really works that way in -HEAD and 7.1R that I have available. But, it's not working when the server is bound specifically to 127.0.0.1 and not any address. Is your server bound to any address? I can connect from 127.2 to 127.1: lab# sockstat -4l USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS root sshd 1386 4 tcp4 *:22 *:* Yet, the connection appears to be connected from 127.2 to 127.2 It doesn't work: lab# sockstat -4l USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS root sshd 1286 3 tcp4 127.0.0.1:22 *:* Hm, just tested with another loopback address from the 172.16.0.0/16 net and it doesn't have the same problem. Could try using something else other than 127.1? That looks like a bug... Nikos