Date: Wed, 03 Dec 2008 13:20:02 +0100 From: "Frank Behrens" <frank@harz.behrens.de> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: freebsd-net@freebsd.org Subject: Re: Problem with new source address selection Message-ID: <200812031220.mB3CK204015947@post.behrens.de> In-Reply-To: <20081203104040.D80401@maildrop.int.zabbadoz.net> References: <200811280653.mAS6r1P3014050@post.behrens.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz.net> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200812031220.mB3CK204015947>