From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 12:20:16 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAA471065670 for ; Wed, 3 Dec 2008 12:20:16 +0000 (UTC) (envelope-from frank@harz.behrens.de) Received: from post.behrens.de (post.behrens.de [IPv6:2a01:170:1023::1:2]) by mx1.freebsd.org (Postfix) with ESMTP id 212538FC13 for ; Wed, 3 Dec 2008 12:20:15 +0000 (UTC) (envelope-from frank@harz.behrens.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=behrens.de; h=from:to:date:mime-version:subject:cc:in-reply-to:references:content-type:content-transfer-encoding:content-description; s=pinky1; t=1228306813; i=frank@harz.behrens.de; bh=fcAxjPXpe3MooGpTtdSyUpAmYXIWYsVMOwFmGSB9flc=; b=Z10vcrzwg6s+zCmDhAW3MCK4q+f5JFcThiugebAEOUChWjltXC5+cAIG81p0DBZAwg6GepIbmLlTDi8cDjLEgQ== Received: from sun.behrens ([IPv6:2a01:170:1023:0:6995:e4a5:5912:409f]) by post.behrens.de (8.14.3/8.14.2) with ESMTP(MSA) id mB3CK204015947; Wed, 3 Dec 2008 13:20:02 +0100 (CET) (envelope-from frank@harz.behrens.de) Message-Id: <200812031220.mB3CK204015947@post.behrens.de> From: "Frank Behrens" To: "Bjoern A. Zeeb" Date: Wed, 03 Dec 2008 13:20:02 +0100 MIME-Version: 1.0 Priority: normal In-reply-to: <20081203104040.D80401@maildrop.int.zabbadoz.net> References: <200811280653.mAS6r1P3014050@post.behrens.de> X-mailer: Pegasus Mail for Windows (4.31, DE v4.31 R1) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Hashcash: 1:23:081203:freebsd-net@freebsd.org::xRdTrwC5zJh9MD3b:0000000000Niv5 X-Hashcash: 1:23:081203:bzeeb-lists@lists.zabbadoz.net::g0r8jrY1niW2gvi8:0000614I Cc: freebsd-net@freebsd.org Subject: Re: Problem with new source address selection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Dec 2008 12:20:16 -0000 Bjoern A. Zeeb wrote on 3 Dec 2008 11:03: > On Fri, 28 Nov 2008, Frank Behrens wrote: > > That works for the router, but for incoming packets on the internal > > interface (from -net 192.168.90.0/24) the machine will send an ICMP > > redirect to new router 192.168.90.2. Of course that is a black hole. > > When I use the route to own interface address > > (route change -net 192.168.200.0/24 192.168.90.1) it works, but also > > for every incoming packet an ICMP redirect is sent. So that solution > > is a workaround for short time only. > > You can disable icmp redircts entirely but not sure if soemthing else > would stop working in your network topology then. > > sysctl net.inet.ip.redirect This is the workaround I made in the meantime. I believe icmp redirects are for a working network not necessary, they are only an optimization. > > Does anybody have a better solution for source address selection? Am > > I the only one with an IPSEC tunnel? > > The best solution actually is to teach your application to bind for > this connection I guess instead of relying on any hack. Hm, is this so easy? I thought address selection for outgoing connections is made by the OS? One of my test cases is bind/named. I don't know how to configure _multiple_ bind addresses for outgoing connections dependent from destination network. As I mentioned earlier I believe the main problem is IPSEC itself, where we don't have an interface for tunneled connections. So I made a workaround with a dummy loopback device. So I have a question to the network specialists: Is there no other solution? Am I the only stupid man, who wants to tunnel a subnet with private address range via IPSEC? > When it comes to the source address selection I am tempted to answer > with: I am willing to still allow this in 7 to not break production > setups but I am inclined to not change HEAD and keep the behavior > dropped there. See patch below, which basically is what you had with > the version check and the if (ia == NULL) check to not blindly overwrite > if we had found anything closer (untested). Thanks, I will try this. Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available.